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.
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 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?
Evan