On Sat, 1 Nov 2003 09:21:35 +0200 Timo Sirainen <[EMAIL PROTECTED]> wrote:
On Fri, Oct 31, 2003 at 12:36:25PM -0800, Vladimir A. Butenko wrote:
> * LIST (\Class("IPF.Appointment") \UnMarked) "/" Calendar > * LIST (\Class("IPF.Contact") \UnMarked) "/" Contacts > * LIST (\Class("IPF.stickyNote") \Marked) "/" Notes > * LIST (\Class("IPF.Task") \UnMarked) "/" Tasks
> What is the general feeling of the community for adding these extra > features which would make IMAP into a groupware protocol. I think that > it is pointless us all trying our own flavours of IMAP to try to get the > clients to work. A specification would solve this, or, should we start a > new protocol specifically designed for groupware.
I don't mind contacts to be managed with IMAP. Sticky notes maybe too.
Calendar and tasks however belong to Calendar Access Protocol. I think it's pointless to duplicate it's functionality in IMAP.
Probably it's a name karma. CAP is as dead as ACAP.
Internet is not an academic institution or a research project. It never was (whatever many who did a lot to develop it thought). It's an enterprise, and the solutions that win are not the best solutions, but solutions that are "good enough", AND that are delivered at the right time at the right place.
iCalendar standards were around for many years, yet no-one delivered any useful iCalendar solution till recently. Recently these things started to pop up as mushrooms on a rainy morning. Developers needed some way to access the calendar store, and CAP was not there. So, they turned to whatever could be implemented quickly - and it was HTTP. It's a VERY INEFFECTIVE method (they usually move the entire calendar store back and force between the server and the client), but it's there, and it works. Case closed (almost). Is it good? From an academic point of view - no. From the point of view of those whose opinions matter - users - it's good: they did not have an iCalendar system, they have it now.
I do not want to say that it's because CAP is a bad idea. It simply lost its chance, as ACAP did. All mail clients can access address books via LDAP. Is LDAP any good? No, it's the worst protocol I've ever seen. But it was there when there was the demand. Now it's very difficult to move to something else.
Speaking of CAP, it's not suitable for today groupware in any case. I do not know if they have changed that, but what about calendaring items with attachments? It's quite a common thing when you send an invitation with an attached document (agenda, illustration, etc.) Neither CAP, not "HTTP/WebDAV" methods handle this very common situation.
There are other things that make calendar/task storage look like a regular mail store with some ADDITIONAL semantics added on top of it. The semantics can be expressed in just few operations, like:
POST <message> - an extension to IMAP APPEND that will remove all other messages with the same iCalendar UID (not to mix with the mailbox message UIDs), according to iCalendar storage rules (or returns an error if the rules say that an existing message is "newer").
FETCH <> - some extensions to IMAP Fetch that will return the view you need (this day, this month, etc), and, probably extensions to FETCH BODY[] (something like BODY[iCalendar]) that will return the parsed iCalendar data.
SEARCH can also have a couple of extensions making iCalendar handling faster/easier.
That's it.
If those extensions existed in IMAP 2-3 years ago, IMAP would become the protocol used by many standards-based Groupware clients that we see today. They were not there, the chance was lost, but the situation is not as bad as it is with CAP. CAP will never fly, because while it provides certain advantages over the HTTP-based "protocols", it does not allow clients to do operations quite common in the real-life groupware products. And those products do treat calendar (and, for that matter, contacts) storage as message store. So, IMAP still has its chance to become the platform for new groupware products, as soon as limitations of the currently deployed HTTP-method become obvious.
Please understand me correctly - this opinion has nothing to do with the fact that we use IMAP for access to calendar and contacts store: we do not have the extensions I mentioned, while we have HTTP-based access to that store, and we can easily implement the CAP interface to that store, as all data, parsers, protocol engines etc. are already there, and implementing a yet another access method is a no-brainer.
I simply do not see CAP as a path to shining future. While IMAP still has its second chance, but the IMAP community should move fast to make it happen.
Sincerely, Vladimir
