[Ietf-caldav] Notifications [was Re: Client work]

[Lisa Dusseault]

It's my opinion that we can do much better than HTTP for notifications 
if we're willing to work a little harder!

I've been working with the XMPP (Jabber) people to first get XMPP 
standardized (we should get RFC #s any day now), then define a 
publish/subscribe model (http://www.jabber.org/jeps/jep-0060.html) for 
arbitrary machine-readable notifications, such as calendar alarms, new 
invitations, changes to shared events.  XMPP is particularly good at 
this because you can route notifications to a specific piece of 
software, by going through the user's single permanent connection to 
their XMPP server.  Also you can easily tell when they're not online 
and avoid routing useless notifications at all.

Lisa

On Aug 13, 2004, at 7:26 AM, Dan Winship wrote:

> On Fri, 2004-08-13 at 01:56 +0200, Helge Hess wrote:
>>> Also, how to make the non-persistent connection model still appear
>>> responsive to users -- e.g. notifications through a notification
>>> channel, to trigger a synch action, rather than constant polling.
>>
>> Exchange uses httpu (HTTP over UDP) to notify clients on changes. I'm
>> not yet sure whether this is a good approach, it might be.
>
> It's not great. It requires the server to be able to source packets 
> back
> to the client, which doesn't work in a lot of situations, notably:
>      1. If the user is behind a NAT (at home, using a wireless hotspot,
>         etc)
>      2. If the user is behind someone else's firewall (at a customer
>         site)
>      3. If the user is inside his company's firewall, but the Exchange
>         server is in a DMZ
>
> But then, the same would be true of any solution that doesn't require
> the client to keep a connection open (unless you assume lots of
> infrastructure).
>
> OTOH, assuming that the client is sending requests to the server on a
> regular basis anyway, the server could just sneak the notifications 
> into
> the HTTP conversation, either via a response header or a new 1xx
> response code. (Both of those seem technically wrong according to the
> HTTP model, but then, notifications are totally outside the HTTP model,
> so that's not surprising :)
>
> -- Dan
>
>