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