On Fri, 10 Oct 2003 16:10:41 +0200 Arnt Gulbrandsen <[EMAIL PROTECTED]> wrote:
The problem usually is to follow the unstated restrictions when writing to >such stores.
For example, I might be able to read all the vcards. But what if I want to >write a new address for an existing name, what should I do? I can imagine at >least two decent ways to do it (delete the current message and write a new >one with two addresses, or write a new one with just the extra address) and >either of them might surprise the existing readers.
Or it might work fine with the version I have, but break the next/previous >version.
--Arnt
There is no well-defined operation of "merging" 2 vCard objects. So I do not think that storing an additional "diff"-type vCard object w/o deleting the original vCard object is an option.
There are other things/problems there, though. When we deal with groupware applications (or any other applications that use mail store as the storage system), we are facing the requirement to be able to modify the data items in the store. A good E-mail server will NEVER EVER allow anything/anybody to modify a message. As a result, the protocols designed to deal with E-mail store (IMAP being one of them) rely heavily (though implicitly) on this fact.
It's not difficult to implement the "Update" (or Replace) operation in a mail store. The problem is compatibility with existing protocols - IMAP and POP, and, more important - with existing clients using these protocols. It is very important to have a "unique ID" of a stored item. But the existing UIDs used in IMAP and POP protocols cannot be used, as there is an ASSUMPTION (not specified neither in IMAP nor in POP protocol specs) that messages can only disappear from a mailbox, but they cannot be changed.
As a result, each "Update"/"Replace" operation must result in a message/item with a new "old-style" UID, and this means that the only way to implement these operations is the MarkDeleted(oldID)+APPEND(newdata). This also means that the items should have some other UIDs, in addition to the POP/IMAP UIDs -so these "new-style" UIDs can be preserved by the Update/Replace operations.
There is an obvious solution for groupware data - vCard and iCalendar objects have "UID" elements. These elements should be stored as Message-Ids of the messages - sorry, I forgot to mention this when I listed the RFC822 header fields that should be created for groupware items in the mail store.
But this "obvious" solution has its own drawbacks - in order to publish an event/task one should parse all messages in the mailbox (or at least, to parse the message headers) in order to find existing copies of the same event/task - and then remove them (or refuse to publish a new element, if the stored one contains a more recent version).
We thought about maintaing 2 UIDs for each message - on the mailstore manager level - a numeric one that acts as the existing UIDs, needed for POP and IMAP protocols, and the second one for UIDs used in the groupware data. The later UIDs do not change when the object item is changed. Being able to handle them on the mailstore manager level speeds up many groupware operations.
These second UIDs are not really needed for Contacts and Notes modifications: when you update a Contacts/Note item, you read it first (so you know its "regular" UID), and when you store the new version, you delete the message with that old "regular" UID. You can even detect a race condition (parallel modification) if you discover that the message with old UID has disappeared.
But manipulations with iCalendar data definitely require something like the second UID, to speed processing of Event "request", "reply", "cancel", and other operations/messages - all of them address the original item by its "groupware UID", not by the old-style "mailstore UID".
All these discussions are about mailstore, they have almost nothing to do with IMAP, which is just one of the protocols used to access a mailstore. But these protocols (IMAP and POP) place quite serious restrictions on the mailstore functionality.
Sincerely, Vladimir
