Sam Vilain writes:
I've performed an initial re-work of the modules list. Please look over the sections of the list that you are most in touch with and provide feedback.
After this stage, I'll try and fit the modules from the existing lists and the Phalanx project into it one by one, and see how I get on.
Obviously this is a moving target; it won't be possible to change the list once now and then stick to it forever more: as modules are written the categories inevitably will have to adapt. In general it's much easier to see as new modules come along where to create (or split) categories; that also prevents premature over-splitting, to make a theoretical distinction between modules that are never written.
In other words, try going through your next step of taking the Phalanx and existing list and putting the modules there into categories -- that'll show how well the categories work in practice much better than people reading though it here will be able to do.
Presumably modules are allowed to be in multiple categories if they happen to do something that pertains to them? (If not the whole thing is very likely to be doomed -- people will think differently about classification, and indeed how to navigate the tree, and having to pick only a single category will lead to many people not finding what they were looking for.)
Related to this, are categories allowed to make multiple appearances? This is the only sane way to deal with categories that have multiple inheritence -- DMoz (Google Directory) does this with some kind of 'symbolic link', where among a particular's category's subcategories are links to elsewhere in the tree. For example some people might think of web interfaces being under 'interfaces', so put a link there.
Again this helps reduce disputes, and avoids the fruitless search for One True Hierarchy.
Networking - raw communication, including IPC:
You have 5 categories that all start "Networking -", which suggests they collectively are really another level of hierarchy.
Networking - providing services:
- Server and Daemon Utilities - Web Services Frameworks: - Apache: - OpenFrame - etc, submissions welcome :) - Web Services Components: - Lots of the Apache sections from above could be moved here - Authentication, Security and Encryption: - Authentication Systems - Encryption algorithm implementations - Security interfaces
It isn't clear to me exactly what these are (except for the 'Apache' stuff), and where CGI-related modules would go, including the 'bigger' run-an-entire site modules such as HTML::Mason, CGI::Application, and the wiki things.
There are also many modules which exist to provide an interface to a particular website (banks, URL-shortners, search engines).
Smylers
I haven't read all of the previous thread, but I would think a catagory scheme like SourceForge.net would be descriptive & flexible enough to provide a better long-term solution. To provide usefull information, the description tags don't neccessarily have to be hierarchical.
Regards, Randy.
