Ethereal-dev: Re: [Ethereal-dev] version numbers of xml and stats_tree?!? Is PACKAGE setting i
LEGO wrote:
xml is about to go... It won't be a plugin anymore. I'm almost done
with the new one (that uses dtds to create the fields) and doesn't use
lex to parse the tvb but a tvb parser API I'll be checkin' in very
soon (this eve if I have time).
Ok, hopefully fixed till the next version.
The stats_tree plugin is an example of a plugin using the stats_tree
API, as the only useful pieces in there were moved to the relative
dissectors. I think it should it be in the source but it should not be
compiled.
Well, maybe compiled, but really not installed (which is currently done
in the Win32 NSIS script). I don't know about the UNIX side on this...
As far as the version string of distributed plugins. I think that the
version should be that of the ethereal version they were build against
(i.e the VERSION macro), and that ethereal should check it to be the
right one and refuse the plugin if it does not match ethereal's
version.
I've thought about something similar.
I would think that the version string should be starting with the
current Ethereal version, appended by it's own version, e.g.:
Ethereal: 0.10.12
Plugin: 0.10.12.3
This way, the version string of the plugin can be increased
independently of Ethereal if some significant changes are made since the
last release and it might stay the same for some Ethereal versions, if
nothing was changed in that plugin.
I didn't had a look if this can be implemented easily.
If the Ethereal and Plugin versions didn't match we might want to have a
dialog box warning about the consequences and asking if it's ok to load
it anyway. This way the user can try to use an old plugin, but he will
get an annoying dialog box every time starting Ethereal and *will* ask
it's plugin provider for a new plugin version soon ;-)
Regards, ULFL
