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/
signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
