Extra Header field

Bernhard Reiter bernhard at intevation.de
Mon Jul 12 18:16:23 CEST 2004


On Monday 12 July 2004 17:23, Stuart K. Bingë wrote:
> On Monday, 12 July 2004 17:00, Martin Konold wrote:
> > > Due to the discontinuity of web-based applications this process entails
> > > two IMAP passes for me - on the second run I do however know the UID of
> > > the object that needs to be loaded, and it would really be ideal to
> > > just do an IMAP search with SUBJECT "uid" to quickly find the
> > > appropriate email.
> >
> > No, I don't like this as it puts a lot of load on the server and
> > therefore limits scalabilty.
>
> Excuse me? Please explain how, while searching for a specific message,
> loading and parsing the contents of every message in a mailbox puts *less*
> load on the server than a SEARCH & FETCH command sequence?

When you completely do the indexes and searching on the client
the server get no additional load. search and fetch would pose massive load.

> > BTW: Does your code have any race conditions with regards to the double
> > parsing?

I think Martin refers to the parsing of one message.
There is no nead to reread the  message for the second parse, I assume.

> No more than any other client, as in it would only occur when two separate
> people are modifying the same message at the same time, at which point it's
> the old "whoever saves first, wins" scenario.

It should result in a conflict with conflict resolution coming up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20040712/83d9895e/attachment.p7s>


More information about the format mailing list