A lot of code and functions are not exported or are private to KMime so it is nearly impossible to add new header classes outside KMime.
It is sometimes needed to create those new header classes, as those classes has more dependencies, like Autocrypt headers that should interact with GnupgKeys and not just plain text. Or headers, that have only a very special usecase, like the X-KMail ones.
It would also nice, if it is possible to register those new classes, so I get directly the translation to those classes, like for all other headers.
Description
Description
Related Objects
Related Objects
- Mentioned Here
- T14903: KMime: Multiple line headers
Comment Actions
The reason for the complexity in the current header code is that this is a performance hot path. The heavily polymorphic design however isn't really suited for that, and thus we have dirty tricks in there like removing the vtable from the private class hierarchy.
So if I had to redo this, the ideal outcome would probably be a single read-only header class that is essentially just a view on a part of the header data and contains all MIME parsing primitives, ie. something that could be entirely allocation-free. More complex header-specific logic would need to move outside, and storage/caching of decoded elements would need to be done by the user where really needed (the message list does that already for example). This would have the additional benefit of also solving T14903 properly, due to there not being a parsed state that needs to be re-assembled.
What's missing in that concept though is API to create/modify headers, this is where the current type hierarchy makes much more sense. Still needs a bit more thought on how to combine those and get the best of both worlds :)