Extra Header field

[Stuart K. Bingë]

On Monday, 12 July 2004 18:46, Martin Konold wrote:
> > > What I want to say: If the header is there it is "the law". If the
> > > header is missing do the parsing as before.
> >
> > This is actually how I used to handle the UID header issue in the old
> > Horde code - if it was not there, I reverted back to loading up the
> > entire message and actually re-saved the offending messages with the UID
> > in the headers.
>
> So your extra effort was only required in case the header was missing.
> Afterwards everything is fine again. I would call this robust and "self
> healing".

Unfortunately in this scenario I assumed that the folder I was loading from 
contained only one type of groupware object - this becomes quite a performace 
hit if you have to assume that *every* type (including "normal" RFC2822 
email) is present, as is the case with the trash folder. If you used my code 
on the trash folder, you would end up re-parsing all the standard email every 
time you load the mailbox, as you wouldn't know whether that message 
contained a kolab groupware object or not. And like Joon has said, the ratio 
of normal email messages to groupware objects in the trash folder is likely 
to be 80% standard messages, which gives rise to a lot of reloading.

> BTW: Can you please explain what kind of UID you are talking about? E.g.
> Outlook knows about an entry id. Kontact also knows about KOrganizer
> UIDs....

In the case of the old code, it was the UID that was present in the 
iCalendar/vCard objects. In the case of notes, I generated my own. As David 
has said, now it is the <uid> tag within our XML objects.

> > Obviously this is not desirable, as it puts a lot of load on the server
> > and therefore limits scalability. I would suggest that we make saving
> > this additional header mandatory, as well as the UID header (and any more
> > that we require in the future).
>
> I am afraid that we start to abuse the mail header as a database.

That is definitely an issue, however currently we have only made the case for 
two additional headers; one that identifies what type of object is stored in 
the message (or if it's a normal message, in the absence of the header), and 
one that identifies the object itself (UID). Using these two facts you can 
quickly get to the message of interest and load any additional information 
that you need, such as the actual content of the object. I can't see us 
needing many more additional headers than this (if we will in fact even need 
any more).

> (The really bad thing about that is that if we make these musts instead of
> hints that we assume coherency)

But isn't that what we're trying to achieve between the clients with this new 
format? Coherency?

-- 
Stuart Bingë
Code Fusion cc.

Office: +27 11 673 0411
Mobile: +27 83 298 9727
Email: s.binge at codefusion.co.za

Tailored email solutions; Kolab specialists.
http://www.codefusion.co.za/