Ethereal-dev: Re: [Ethereal-dev] 0.10.10 next week?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Olivier Biot (Ethereal)" <ethereal@xxxxxxxxxxxxxxx>
Date: Sat, 5 Mar 2005 12:01:16 +0100
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