Hi everyone, had a chat with Chen on IRC today about the topic. Since he had to leave, I'll try to sum up our findings here, for the record and for review, please see the inline comments. Am Mittwoch 23 Mai 2012, um 10:00:27 schrieb Christian Hilberg: > Am Dienstag 22 Mai 2012, um 16:38:20 schrieb Christian Hilberg: > > Hi again, > > [...] > > Seems the solution which is now in Git master solves only part > > of what is needed (or I am missing something, in which case I > > will happily accept correction). > > Let me just drop a short summary of what we've come up with so far: > > * The IMAPX tokenizer is not extensible with the current gperf > implementation. New tokens will need to be added for untagged > responses and for server capabilities at least. > > * We need a way to extend the server capabilities flags, so they > will be set according to what the server advertises (for now > it will be ANNOTATEMORE, METADATA and ACL, maybe more) > > * The current *IMAPXExtUntaggedResponseHander (should not this > be "Handler" instead?) function pointer prototype lacks a > possiblilty to pass in and out some user payload data. > [...] > > * The current *IMAPXExtUntaggedResponseHander does not have > a token parameter for me to tell exactly which token has > been read from the stream so I can decide my action It turned out in our discussion that if we followed the current implementation (that of an additional response handler the way CamelIMAPXServer now implements it) would suffer from the above mentioned issues. Passing in the user payload data showed to be specifically tricky. Since the current handler function would need to be able to care for more than one untagged response, passing in the placeholder pointers to payload data (e.g. folder annotation data, which gets processed by the handler function and needs to be put somewhere) would become tricky. Binding the user data to a given CamelIMAPXJob is also not an option, since it has already been pointed out that matching the currently active job inside an untagged handler is problematic (see [0] and [1]). A different approach to making the CamelIMAPXServer extensible and which provides a way to solve all of the issues mentioned above, IMHO is a table based approach for the untagged handler. Each untagged response would be associated a certain handler function (pointer), and these be held in a hash table or somesuch (I guess there are faster ways to do this). The handler functions would then be indexed by the untagged response token ID. A working implementation for this exists in the old (2.30) evolution-kolab version of CamelIMAPXServer, see [2]. It is all there, waiting to be cannibalized and used upstream. This implementation, however, has not been done with extensibility in mind, so that part would have to be tweaked. It would also mean to ditch the gperf approach for generating the token hash tables, since the gperf thing is not extensible. Given a table of function pointers would exist in CamelIMAPXServer, and a function to add more functions, this would solve the extensibility in a neat way. Also, along with added untagged response tokens, there may come added server capabilities (ANNOTATEMORE/METADATA for me, ACL being another candidate, and more out there in the IMAP RFCs), so I would need to be able to register these and have a way to check whether the server advertised the capability or not. Chen asked me for a week's worth of time to look into this. I am convinced that the idea outlined above would be a nice solution, as in the old code, it collapsed the imapx_untagged() function to almost nothing. I would be happy for input - if you see any flaws or if you have good ideas for solving the missing pieces (like, how to pass in and out userdata locations in the handlers in a sane way), please let us know. Kind regards, Christian [0] https://bugzilla.gnome.org/show_bug.cgi?id=676548 [1] https://bugzilla.gnome.org/show_bug.cgi?id=667725 [2] http://git.gnome.org/browse/evolution-kolab/tree/src/camel/providers/imapx/camel-imapx-server.c?h=gnome-2-30#n1363 -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.