Hi again, finally got my hands on that piece of code now, but see below. Am Donnerstag 10 Mai 2012, um 12:26:51 schrieb Chenthill: > I hope you had sent the mail just before our irc discussion. To > summarize, > https://bugzilla.gnome.org/show_bug.cgi?id=674310#c9 has the fixes. We > now have a hook in imapx_untagged which would allow the subclasses to > handle the responses that are not handled in IMAP (imapx provider). I > did not find a case where a sub-classed imap provider would be > interested in tags which are already processed by the parent imap > provider, so i have provided a simple hook to handle, unhandled tags. I > hope this would be sufficient to support all the above needs. > > Please let me know if you need anything more.. 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). There are at least these issues I see: camel-imapx-tokens.txt is the file which is fed to gperf, and the resulting structs are used by the IMAPX tokenizer. The tokenizer is called inside imapx_untagged, and its result is switch()ed on, and the extended untagged handler function, which can be registered, is called in the default: block of that same switch statement. To make the IMAPX tokenizer aware of new IMAP tokens, these need to be added to camel-imapx-tokens.txt AFAICS. This I did for the 2.30 and 3.4 lines of evolution-kolab, and it worked. I can't see how I should add new tokens to the tokenizer now. The to-be-registered untagged handler function is called after the tokenizer has already run, but without knowing the new tokens this extended handler cares for. What does happen now? Is the new token still sitting there in the CamelIMAPXStream, waiting to be tokenized? Does that mean I need to write my own tokenizer, or duplicate the one already existing in the CamelIMAPXServer? If it was planned that the tokenizer be extended in some way, then the signature of the extended handler is missing the token that the tokenizer has found, so the registered response handler can decide what to do. Next, the tokens I need to care for in the evolution-kolab case are associated with certain server capabilities. Again, for the 2.30 and 3.4 lines of evolution-kolab, I've added new capability flags to the server so I can check that in my own handler function. While that check could, in theory, be omitted, I need it to decide the protocol type for metadata (ANNOTATEMORE or METADATA (planned for)). The same will hold true for IMAP ACL, which will need to implement later on. Unless we can resolve these issues, I am stuck with porting from 3,4 to 3.5, and I've already missed 3.5.1 release (and would not want to miss 3.5.2 as well). This thing is rather urgent. Kind regards, Christian -- 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.