From: Lars Roland
There's is one good reason for a dissector or what else, to be a plugin.
If it is experimental or still on an early development stage, you can have
an option in the installer.
I agree. It's up to the maintainer of this plugin dissector to keep it
up-to-date with the source tree.
I agree, we have a lot of plugins stable enough to be part of ethereal
itself.
We should depluginize them.
Here I also agree.
So we come to another discussion I want to start here.
How about grouping dissectors together in sub directories of
epan/dissectors?
Interesting idea. However...
I don't like to have 700 files in just a single directory.
I'd like to suggest following groups for dissectors:
- Layer 2 Protocols
- Layer 3 Protocols
- Layer 4 Protocols
- ASN.1 based protocols
- text based protocols, e.g. HTTP, SIP, MGCP (depluginized), ...
- dcerpc dissectors
- aim dissectors
...
If we're going to split up the dissector sources in a directory structure,
I'd favor *today* using the protocol families as a discriminator. I don't
want to reinitiate the OSI layer discussion here but some protocols are used
at different levels, so you cannot always say "protocol FOO is layer N".
Consider for instance the HTTP-lookalike dissectors in packet-http.c...
If we're going to spread the dissectors over such a directory tree, you will
then require a "map" explaining where a given protocol dissector will be
found. Otherwise it'll be hard to maintain for novice developers, which will
require to answer the question "where does this dissector belong" and might
prevent some developers in contributing code...
I am really curious on the other proposed solutions!
Best regards,
Olivier
