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. > 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]). Received correction on IRC. Let that be "should be avoided, if possible", instead of "is not an option". Moreover, as pointed out above, at least for my case, it is not even needed. One issue solved. :) 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.