Evan Huus skrev 2012-08-30 16:27:
On Thu, Aug 30, 2012 at 9:45 AM, Graham Bloice
<graham.bloice@xxxxxxxxxxxxx> wrote:
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-
bounces@xxxxxxxxxxxxx] On Behalf Of Evan Huus
Sent: 30 August 2012 14:31
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] RFD: Creating subdirectories in
epan/dissectors/
On Thu, Aug 30, 2012 at 9:23 AM, Roland Knall <rknall@xxxxxxxxx> wrote:
Hi
Would you like to enforce a value for the minimum number of subsequent
files in the subdirectories?
I would assume you'd need 5 or 6 files at least to make a folder
worthwhile,
but I don't think that's a hard rule. None of the groups proposed for
the initial
run have less than 14.
As I wrote the opensafety package, I would like to split it up a
little bit to make it more maintainable, as well as include two new
subdissectors, which use the openSAFETY protocol, but are not
necessarily part of it.
For the subdissectors, it depends on how tightly they are bound to
opensafety. If they could theoretically be carried on other protocols as
well
then they shouldn't be grouped with it, but if they are restricted to
opensafety (in the sense that they use some special fields or features
of
opensafety and so actually couldn't be carried on, say, TCP, without
changing
the protocol), then they can logically be grouped with it. Again,
probably not
a hard rule, but a good guideline.
[Graham Bloice said]
Some folks have articulated the drawbacks (to them) of making these
changes but I haven't seen any actual advantages listed. Can anyone list
them as they see it?
I think it boils down to better structure and scalability. We have an
enormous number of files in epan/dissectors/ and I fully expect it to
continue to grow. The flat structure is already unwieldy and it's only
going to get worse.
Logically grouping certain dissectors reduces the number of items at
the epan/dissectors/ level. It also makes it much easier to work on a
single cluster: if you're working on some enhancements to the
bluetooth dissectors, it's much easier to work in
epan/dissectors/packet-bluetooth/ than to try and wade through all the
other hundreds of files in epan/dissectors/ every time you need to
open another bluetooth-related file.
- If we make sub directories I'd vote for epan/dissectors/bluetooth
It should also make the groupings easier for new developers to grok.
It's pretty obvious that everything in packet-bluetooth/ must be
bluetooth-related, even if the filename is something like
packet-hci_h4.c (which is a real bluetooth dissector file, for those
who didn't know). *I* know that "hci" stands for Host/Controller
Interface which is a bluetooth-related term, but only because I looked
it up for the purposes of this email, and I still don't know what the
"h4" is. New developers shouldn't have to do that kind of research (or
peek at the file header) to get an idea of what a dissector does.
Arguably each dissector should have a short description of what it does
and preferably references to protocol descriptions including an
explanation of the acronym.
Arguably my last point could be fixed by just using better names in
epan/dissectors/, but then you end up with names that are
uncomfortably long:
packet-bluetooth_host-controller-interface_hsomethingsomething4.c
anyone?
I'm not convinced having a small number of subdirectories alleviates the
"problem" of a large number of files
in epan/dissectors trying to group a larger number of dissectors in a
logical way might not be easy. If we
end up with > 100 subdirectories that wouldn't be nice either.
That said moving dissectors split over many large files might make
sense, if the files are small
perhaps they should be folded into the main one as modules instead.
Evan
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
