And again... Am Mittwoch 23 Mai 2012, um 18:40:34 schrieb Christian Hilberg: > Hi again, > > Am Mittwoch 23 Mai 2012, um 18:05:29 schrieb Christian Hilberg: > > Passing in the user payload data showed to be specifically tricky. > > As dwmw2 just pointed out on IRC, it really isn't. > The data structures which the derivative untagged handlers > need to access can/should best be bound to the derivative > CamelIMAPXServer. In fact, that is exactly the way it works > in my 2.30 approach, only the data structures were not bound > to a derivative, but to the original CamelIMAPXServer. Binding > to the subclass would be the only change needed here. ...which would mean subclassing CamelIMAPXServer. In the currently implemented scheme, CamelIMAPXServer would not be subclassed, but only a handler function registered (which indeed would have trouble accessing the userdata). If we want to subclass CamelIMAPXServer, we also need to modify the connection manager, so instead of the stock CamelIMAPXServer, the derivative class is instantiated and returned when the derivative store object requires a new connection. A working implementation of this can be found in the gnome-3.4 branch [0] of evolution-kolab, though things are somewhat complicated there (CamelIMAPXServer and CamelIMAPXConnManager do not use virtualized functions there, so subclassing meant to re-build the code paths in question - that should be possible in a simpler way with the current 3.5 line of E-D-S). Kind regards, Christian [0] http://git.gnome.org/browse/evolution-kolab/tree/src/camel/providers/imapx?h=gnome-3-4 -- 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.