Hi folks, Am Dienstag 22 Mai 2012, um 19:04:45 schrieb Matthew Barnes: > On Tue, 2012-05-22 at 16:38 +0200, Christian Hilberg wrote: > > camel-imapx-tokens.txt is the file which is fed to gperf, and the > > resulting structs are used by the IMAPX tokenizer. > > The tokenizer is called inside imapx_untagged, and its result is > > switch()ed on, and the extended untagged handler function, which can > > be registered, is called in the default: block of that same switch > > statement. > > At this point I would advocate ditching gperf and just building an > internal hash table of known tokens which subclasses can extend. I'd second that. > The > tokens could be internalized with g_intern_string() to save a few string > comparisons, but I can't imagine that's a huge performance hit in the > face of network I/O. It would mean one build requirement less, too. > I haven't really looked closely as how gperf is used within the parser, > so this is admittedly hand-wavy. But clearly a static hash function > built from a text file is not going to be extensible the way we need. I had a short look at the gperf docs, and it apparently cannot be fed with several files. Moreover, for gperf being able to build perfect hash tables, it would need to read all of them (the original IMAPX one and all extending ones) at once. Given the IMAPX extensions live in separate modules, this approach would not be maintainable. 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.