Event UID in the Subject?

Stuart K. Bingë omicron-list at mighty.co.za
Wed Jul 14 13:16:07 CEST 2004


On Wednesday, 14 July 2004 12:41, Bernhard Reiter wrote:
> I think I have described this in detail in my email from yesterday 18:37
> Message-Id: <200407131837.47538.bernhard at intevation.de>.
> Did you see that message?
>
> > Yes that is essentially the main algorithm. Please, I'd love to hear your
> > counter-arguments - you see very adverse to having the UID in the
> > Subject, so I assume you have some valid arguments against the scheme.
>
> In short: Trying the imap uid first will save the search in most cases
> (my estimation: 98%). You only need to save one additional value per
> event to use that improvement.

A couple of points:

Firstly, please could you provide some benchmarks or other quantifiable data 
that identifies SEARCH operations on Cyrus to be considered "slow". I am 
under the impression that Cyrus caches the headers of messages, meaning 
searching would be quite quick.

Secondly, while this whole UID caching mechanism that you and Martin have put 
forward does seem like a good idea, I really do not consider it practical.

You see, it's not just "one additional value" that I would have to store - I 
can't add arbitrary values to the event hashes (well I can, but I can't 
retrieve them later), meaning I would have to implement a EUID -> IUID 
mapping (EUID = Event UID, IUID = Imap UID) within the PHP session. As I've 
said previously - all I get is a "retrieve the object with UID X" call.

The UIDs that are used in Horde are at a minimum 32 characters long (MD5sums), 
however it is often the case that a UID is 64 or possibly more characters 
long, as we also use the UID to resolve which share (message folder) the 
object (mail) is actually stored in (*).

And the problem is, this mapping would have to cater for every message I read, 
within every message folder I touch, for every user of the webclient, for a 
reasonable time period as I do not know when the next page load (message 
request) will come through, as again, I've said before. Oh yes, and then 
there's the UIDValidity problem as well.

Now *this* "puts a lot of load on the server and limits scalability", as this 
would be done through PHP scripting in the session cache. Not a very 
practical/desireable solution.

I'm not sure if you've used the webclient yet, but without a PHP accelerator 
it's really not that geat an experience to try. Horde is already a massive 
system without this gargantuan caching mechanism that has been proposed. That 
is why I would like to offload a lot of this probable "caching" performace 
hit to the IMAP server (which translates to a little hit to Cyrus, ala the 
SEARCH), and let Horde concentrate on providing web-based groupware 
functionality, as opposed to mirroring the data that Cyrus already holds.


(*) This is done to cater for iTip requests  - when we send out an event/task 
request, etc, and receive a reply, we are given the UID of the corresponding 
object and a major optimisation for this is to know exactly where to find the 
message that contains the object, purely based on the UID (i.e. the UID also 
identifies the share that contains the object). If this were not the case we 
would have to search through *all* messages in *all* the users' (and possibly 
shared) folders to try and find the coresponding groupware object to update 
it as necessary, as we would have no idea where it originated from.

Hopefully this little diatribe reveals a bit more of the problem I am faced 
with, and why I think that a UID header is A Good Thing.

I really don't mind if it's not implemented in the standard though - all that 
that means is I will revert to my old mechanism of manually putting in the 
UID headers for messages that don't already have them present. The only 
reason I asked to put this in the standard is to enable me to optimise my 
code a little, and thereby increasing Horde's performance, by taking out the 
"if (!present(UIDheader)) { insertUIDheader(); rewriteMessage(); }" code.

Either way, I will be using the UID within the headers. I will also gaurantee 
to preserve the headers, for any other clients that wishes to add any 
additional headers themselves.

Regards,

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




More information about the format mailing list