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. All the best, Evan ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
