[standards-jig] Calendaring - Requirements & Goals

Justin Kirby justin at openaether.org
Mon Jun 2 02:09:56 UTC 2003


I see calendaring support in jabber as two levels. 

A basic ical wrapper similar to ical attachments in email, so jabber
becomes nothing more than a transport. Where the end jabber client would
just hand the ical data off to the calendaring app on the system.

and a native jabber calendaring groupware system where all the unique
features of xmpp/jabber can be used and abused. Such as pubsub, iq,
presence, auto-conference session et al.

For right now a simple "this is how you transport ical" would work. So
end point clients could start passing the data off to evolution &
lookout.

The "native" groupware extension will probably end up being several jeps
and a huge multi year head bashing effort to get it all finalized and
accepted by the council. 

As mentioned earlier chandler is definitely a project that should be
looked at and possibly used as a springboard for the full groupware
support. Especiall given that they are already using jabber as a
communications protocol...iirc.


For kicks I started a wiki, I know this list doesn't like wiki's for
some strange reason... to start it off I stole content from rob's and
theo's sites. Feel free to abuse it.
http://www.openaether.org/wiki/index.php?GroupWare%20Protocol


Justin


On Sun, 2003-06-01 at 20:06, Robert Norris wrote:
> > Before we go further on this, how about we first come up with what our
> > requirements and goals are?  While these "details" might seem obvious, I
> > have seen many a project fail because of this, some quite spectacularly.
> 
> After jabberd2 is finished (some time next century), my plan is to work
> on an enterprise-grade group calendaring server, since there really
> isn't an open-source option for something like the Sun or Oracle
> calendaring stuff.
> 
> I've documented things briefly here:
> 
>   http://cataclysm.cx/projects/calendar/
> 
> My plan is to use Jabber as the underlying interconnect between the
> various pieces of the server (clients, database, etc). It seems to me
> that the entire application can be reduced to a series of pub/sub
> operations, which will make Jabber ideal.
> 
> However, I don't know that the end-user interface will be a Jabber IM
> client, necessarily - its entirely possible that the external interfaces
> to the system will be iMIP/iTIP, and not XMPP at all.
> 
> It seems that we should be thinking of calendaring as an application in
> the same way we think of IM as an application - a set of protocol
> extensions to the XMPP core. In some places there may be interop with
> Jabber IM (exchanging events with friends, receiving notifications, and
> shared account/vcard information), but that doesn't necessarily mean
> that all Jabber IM clients will become Jabber Calendar clients too.
> 
> So, what do other people think of when they think of Jabber Calendar?
> 
> Rob.




More information about the Standards mailing list