Am Dienstag 22 Mai 2012, um 16:38:20 schrieb Christian Hilberg: > Hi again, > [...] > 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).
Let me just drop a short summary of what we've come up with so far:
* The IMAPX tokenizer is not extensible with the current gperf
implementation. New tokens will need to be added for untagged
responses and for server capabilities at least.
* We need a way to extend the server capabilities flags, so they
will be set according to what the server advertises (for now
it will be ANNOTATEMORE, METADATA and ACL, maybe more)
* The current *IMAPXExtUntaggedResponseHander (should not this
be "Handler" instead?) function pointer prototype lacks a
possiblilty to pass in and out some user payload data. In
evo-kolab, for instance, the ANNOTATION untagged response
carries folder annotation data, which I need to insert into
a hash table. That means, I would need to pass in a pointer
to that hash table. Given the fact that I can only register
*one* handler function, which means that in the same handler
function I need to process a number of tokens (ANNOTATEMORE
and METADATA in my case), which may not share a common data
structure to put the payload data into, things will become
complicated in the current approach. I would need to pass
in a struct, which will be extended with new payload data
location pointers each time a new token is added to my
handler function
* The current *IMAPXExtUntaggedResponseHander does not have
a token parameter for me to tell exactly which token has
been read from the stream so I can decide my action
Seems to me that an extensible table of registered handler
functions would not be that much more of an overhead, and as a
side effect, it would nicely cut down that nightmare switch
statement called "imapx_untagged". :-)
Kind regards,
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 [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
