Extra Header field

[Bernhard Reiter]

Hi Joon,

On Tuesday 13 July 2004 07:06, Joon Radley wrote:

> > My suggestion was to rely on the mandatory annotate and
> > accept the extra parsing effort for special cases like the trash-can.
> > If you hit something in the folder that is not the type as
> > indicated in annotate, you just ignore that email and
> > possibly  issue a warning about the number of ignored emails
> > (see my other email).
> >
> > > Parsing a big MIME message is resource intensive.
> > >
> > > Adding this header to the message will not affect the format or the
> > > storage, why is it such a problem?
> >
> > I am not saying it is a big problem, I am just curious about the need.
> > If we do not need it than I also like to not duplicate information.
>
> Lets take an example. We have 100 items in the trash folder. We assume that
> 95 of them are RFC2822 messages and 5 are Kolab format objects. This should
> be the ration all over the system.

>
> As the main header of each message is read we will disregard this in the
> equation.
>
> 1) Without an extra header: 100 message must be parsed in order to
> determine the object type.
> 2) With optional extra header where 60% of the developers elect to
> implement it: 97 messages must be parsed.
> 3) With mandatory extra header: 0 messages must be parsed.
>
> From this you can see that the mandatory extra header vastly improve
> decision making when deciding on message type.

Yes for the trashcan folder, which I considered an exception.
Normally a user would have about 10 kolab object related folders
and only one trashcan folder. He only needs the parsing done on the objects
in the trashcan when looking into the trash can to try to recover an object.
This seems to be a rare operation to me (probably 2% of all looked at emails).

So the question for me came down to if that doubling of information
and that extra rule is worth the bit speed up that rare cases.
If my number of 2% of the usual cases that get a speedup from this
is correct I would have the tendency to say we can live without the header.

-------------- 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/20040713/2186ae04/attachment.p7s>