Re: Reshaping the modules list: a starting point, help remove the bias.
Hi, within the development cathegory, I think it would be good to separate modules that are for the perl interpreter (debugging, profiling, ...) and other development tools. As an example, I have a module called Devel::Cpp which I put tin the Devel root because I foun no better place (and I didn't ask either :-( but later on I understood that Devel was not for this kind of devlopment tools (I'm still wondering why). Now, there is a new pure perl preprocessor module that I want to use instead for 'cpp', I still don't know where to put it! Cheers, Nadim.
Re: Reshaping the modules list: a starting point, help remove the bias.
On Wed, 25 Feb 2004, Sam Vilain wrote: Pure data and structures: - Pure algorithm implementations (c.f. C++ STL) - Class generator frameworks - Parameter parsing modules - Data Schema modules - tree-based (eg XMLSchema) - Data Schema modules - general (eg YAML::Schema) - Code modelers and CASE tool plug-ins - Classic CS data structures (b-tree, heap, etc.) - Date Time modules - Internationalisation and Localisation I think this actually belongs in a top-level category. It's pretty important, and it isn't necessarily something someone would think of as string-related. - Object/Relational mappers hybrids * Relational/Object mappers (Alzabo Class::DBI go here) Imaging, Images, Multimedia: - Sound manipulation - Image Conversion - Raster Image Manipulation - Vector Image Manipulation How many people think of this as Raster vs. Vector? - File Archiving - File Compression I'd combine these, since things like zip files are both, and there's not _that_ many modules in this space anyway. I think we're missing some categories: - Module instalation and creation - CPAN, CPANPLUS, Module::Build, Module::Install, etc. - Templating systems (maybe under the String/Natural language category) - Application frameworks (Mason, CGI::Application, Maypole, AxKit, Pipeline?) - Logging Debugging support (under Code Development, I'd think) Also, I think Randy's suggestion of a Sourceforge Trove-style implementation is a good one. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Reshaping the modules list: a starting point, help remove the bias.
Ah, there's also no math or statistics sections there. Please, someone in the field beat me to it :) -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) Beauty is only skin deep, but Ugly goes straight to the bone.
Re: Reshaping the modules list: a starting point, help remove the bias.
[EMAIL PROTECTED] (Leon Brocard) writes: I don't really see the point of the modules list any more. search.cpan.org and CPAN.pm/CPANPLUS don't use it. Most modules aren't on it. Shouldn't we just give up on it? That's weird. I said that too. But then, if people want to spend time on this, I don't see the harm. -- The best index to a person's character is a) how he treats people who can't do him any good and b) how he treats people who can't fight back. -- Abigail Van Buren
Re: Reshaping the modules list: a starting point, help remove the bias.
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
Re: Reshaping the modules list: a starting point, help remove the bias.
On Wed, 25 Feb 2004 02:32, Leon Brocard wrote; I only skimmed the discussion before. What problem are you trying to solve? Locating and selecting a module to perform a particular task can be time consuming, and daunting for the novice. Authors often don't find what they want, and end up re-inventing wheels unnecessarily, when they could be (and I would guess would rather be) re-inventing suspension coils and inventing low speed differentials. Perhaps you're personally happy with search.cpan.org, but a little extra directory and indexing information can't hurt for those who can't discern the coding prowess of the author at a single glance at an API, and who don't hang out with Perl geeks for 90% of their waking hours. The relevant review information may be out there on use.perl.org, perlmonks.org, etc, you might say, but if they are all in one place they are more likely to be kept current. It might make CPAN look a bit tidier as well :-). -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) Sarcasm is not the lowest form of wit. Sarcasm is the sour cream of wit. Puns are the lowest for of wit, for which someone should be drawn and quoted. - Fred Allen (adaptation)
Re: Reshaping the modules list: a starting point, help remove the bias.
On Wed, Feb 25, 2004 at 07:25:16PM +1300, Sam Vilain wrote: On Wed, 25 Feb 2004 02:32, Leon Brocard wrote; The relevant review information may be out there on use.perl.org, perlmonks.org, etc, you might say, but if they are all in one place they are more likely to be kept current. I use the list a lot. I wasn't even aware it wasn't kept relatively up to date. It's quite handy if you want to find a module that does X, but you're not sure exactly what the correct terminology for X is. There's also the gee that's neat, maybe I'll try that out factor. YMMV. Austin
Re: Reshaping the modules list: a starting point, help remove the bias.
On 02/24/04 13:51, Smylers wrote: 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.
