> -----Original Message----- > From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- > boun...@wireshark.org] 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. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe