Wireshark · Wireshark-dev: Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/

[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-
> bounces@xxxxxxxxxxxxx] On Behalf Of Evan Huus
> Sent: 31 August 2012 03:15
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] RFD: Creating subdirectories in
> epan/dissectors/
>
> Having re-read the entire thread, I've gathered the following list of
> objections. I think it covers all of the concerns mentioned so far (in
no
> particular order):
>
> 1 potential for file-name collisions
> 2 increased difficulty in using tab-completion
> 3 potential for less parallel make
> 4 more complicated to search dissector source
> 5 concern that the number of folders would scale as poorly as the number
of
> files
> 6 concern that it wouldn't actually provide any benefit
>
> 1 and 2 are only issues with the original, rough draft of the naming
scheme.
> The refined naming scheme proposed later in the thread does not have
> either issue.
>
> 3 is only an issue if we write the makefiles wrong. Now that somebody's
> mentioned it, hopefully we wouldn't make that mistake :)
>
> 4 is valid, but minor. I would hope that most developers use a tool like
ctags,
> cscope, or similar to index the code. All of those tools will work
regardless of
> how the source is layed out. Manual greps will be more complicated, but
if
> you have to run a manual grep on a codebase the size of Wireshark's then
I
> think there's already something wrong.
>
> 5 is reason to be conservative in our use of folders, but not reason to
discard
> the idea. As long as we limit folders to groups with a large number of
files
> (10+? more?) then they'll still provide a benefit. 1000 folders is way
too
> many, but it's still better than
> 15000 files!
>
> 6 I'm not clear on, since the benefits seem so obvious to me. Perhaps
I've
> just done a poor job of explaining. I simply feel that
epan/dissectors/packet-
> bluetooth/ would be a good thing for the same reason that
epan/dissectors/
> is a good thing: it provides additional logical structure that turns a
list
> (inefficient) into a tree (efficient). If people are more in favour of
using
> patterned names like packet-bluetooth-* to denote that structure, then
why
> do we use folders at all? As Jeff pointed out, we moved all the
dissectors
> together into epan/dissectors/ for a reason. That reason still applies
here.
>
> At this point I feel that I've said everything I can possibly say on the
subject. If
> people are still generally against the idea then so be it, but I'm not
going to
> argue the point anymore.
>
[Graham Bloice said]

Evan,

Thanks for the list it was really helpful.

FWIW my vote is not to change, I don't find the current layout difficult
and I see no personal benefit if it were changed.  Any changes to use
subdirectories would inconvenience me as my preferred editor would then
have to be set to search sub-directories when "grepping" for dissector
stuff, as would my muscle-memory when grepping from the command line.
However if the group think is to change things then I'll cope.

I would support removing the "packet-" prefix though.  Entirely
unnecessary IMHO.