Re: Testing

[brian moseley <ix maz org>]

On Wed, 8 Dec 1999, Miguel de Icaza wrote:

> Camel does not handle iCalendar, Camel is a Mail API.

a camel provider could very easily take icalendar off the
wire and populate camel data structures. icalendar is
already name-value based, so it fits fairly well with the
folder+message api, although there would probably need to be
convenience methods for extracting icalendar property
parameters and property values from the 'mime headers'.

im told exchange and other systems are message-based in this
fashion underneath; they definitely are from a ui point of
view.

given icap and cap imip and all the other legacy calendar
standards that exist today, it makes sense to utilize a
provider structure similar to that of camel. and given that
the data is accessed and manipulated in very much the same
way, it seems reasonable to extend camel where necessary.

> So, what is your company iCap server?  is it GPL?

haha no, its proprietary. however, since i use critical
path's mail and calendar services for both work and the
domains i host on my personal server, i have definite
interest in making my desktop software interoperate with
cp's servers.

i dont think ive ever seen an open source icap server (its
ICAP btw, basically created by copying imap and
s/mail/calendar/g). however there are open source icap
client libraries popping up these days, so it wouldnt
surprise me if somebody put a server out in the near future.