Hi Matt, Am Freitag 03 Februar 2012, um 16:46:50 schrieb Matthew Barnes: > On Fri, 2012-02-03 at 15:53 +0100, Christian Hilberg wrote: > > I need to replicate some code paths of IMAPX (e.g. all paths that > > lead from the Store to imapx_untagged, so I can extend this one > > for ANNOTATEMORE and later IMAP ACL). Hence, there is some IMAPX > > code duplication I cannot avoid at present. > > > > This means that for every (major) change in upstream IMAPX, > > I need to pull the changes in and check whether I need to > > fix something in my code dupes. > > Would it help you much to turn imapx_untagged() and similar functions > into virtual class methods in CamelIMAPXServerClass? Then you could > override the method in your subclass, and have it chain up first and > then do other custom stuff. That would definitively make things easier. As far as the CamelIMAPXServer goes, extending imapx_untagged is the main objective. In fact, for 2.30, I've added a few more switch cases to imapx_untagged and did no more than calling one of my own functions there. (I did a little more - we've talked about that table based approach where I turned almost all of that giant switch statement into a function table, leaving only a few case's to be handled - it is all there in evo-kolab's gnome-2-30 branch, but has never gone upstream). > Or does the logic not allow you to break things out that cleanly at > present? (wouldn't surprise me) I don't think that my own logic would get into the way here. Now that you've mentioned it - we were thinking and talking on IRC how to change imapx_untagged for a table-based approach (a function table that is, with one handler function per untagged response and its index being the untagged response code). For that, I think you mentioned a vtable bound to the object (class?), to make the whole thing extendable. I see the imapx_untagged-upcall you mentioned above fit into this scheme. Extend the vtable, and in your local implementation of imapx_untagged, call the parent object's imapx_untagged first, then check whether the response has already been handled (in which case you're done and return), or whether parent's imapx_untagged tells you that there is a response pending and still unhandled, so you, the derived class, may have a handler for it. You check, and yes, you have an entry in your extended vtable for the particular response code (means, the list of known response codes also needs to be extendable, that could be a tricky part with the current gperf thing for generating that), and you call your handler. That is, with the untagged response code, index into the vtable, get the function pointer and make your call. imapx_untagged would be required to set a specific error if the untagged response could not (yet) be handled. As the implementor of a subclass, after upchaining to the parent handler, this would allow me to decide whether there may be work left to do and I can check whether I have a handler for it. If I do _not_ have a handler, I do propagate that error, so either a subclass of mine would know that there may be work left to do, or the original caller would know whether there was no handler for the response code in the inheritance chain. Whether or nor a parent's existing handler for a specific untagged response could be sensibly overridden with this construction might be worth discussing (or whether it should even be possible - might not be a wise idea to make that possible). Dumping a few bits, 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.