Guy Harris wrote:
We should avoid using "class" as a structure member name, or as
anything else that makes various Ethereal APIs unusable in C++.
Agreed.
That means renaming the "class" members of ber_sequence_t and
ber_choice_t (presumably your dissector is for a protocol using
BER-encoded ASN.1). Any votes on what it should be renamed to?
The right way to get rid of the problems with Xplugin_api_decls.h is
to ensure that an Ethereal plugin can be built without using any of
the "plugin API" mechanism - it should be possible to link it against
the libethereal library and have it directly refer to functions in
libethereal without having to go through pointers. The "plugin API"
mechanism was a hack used before libethereal was a DLL that let us, on
Windows, export its functions through standard DLL mechanisms; the
only reason I see to keep it around is to allow older plugins to
continue running, but, as we don't guarantee that the plugin ABI will
remain the same from release to release, we can't guarantee that older
plugins will continue to run in any case.
Is there any good reason whatsoever to continue to keep the "plugin
API" around? It's a pain to maintain it.
I do agree that the maintenance is a pain, so I don't have any problems
removing it.
But before removing it, please update the documentation *before*. I'm
thinking of /doc/README.plugins and /plugins/README.interface.
Unfortunately, I don't have enough knowledge of doing so.
Regards, ULFL