Extra Header field

Joon Radley joon at radleys.co.za
Tue Jul 13 07:06:01 CEST 2004


Hi Bernard,

> 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. 

Best regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za




More information about the format mailing list