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.
On Wed, 25 Feb 2004, Sam Vilain wrote: > 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. I think the main reason the modules list as it stands is not that useful is _because_ it's not being actively maintained and re-organized/categorized as needed. If someone (Sam) were to take on this task, I think it could become much more useful. Plus the current module list is integrated into search.cpan.org, it's just that no one uses it ;) The top page includes links for the module list categories! -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
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: > > 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. To put it simply, it's needed for the same reasons that http://directory.google.com/ is needed. Tim.
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.
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 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 Tue, Feb 24, 2004 at 04:16:33PM +, Simon Cozens wrote: > [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. I figure META.yml could have an entry for the category (categories?) that the module author thinks the module should be listed in. (Though to limit the impact of inevitable typos it might be best to assign a short 'tag' name to each long category and have META.yml use that.) Tim.
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.
[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 sent the following bits through the ether: > I've performed an initial re-work of the modules list 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? [If you want similar functionality, giving modules keywords might be a way to go, but I'm not entirely convinced either] I only skimmed the discussion before. What problem are you trying to solve? Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Todays subliminal message is " "
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.
Reshaping the modules list: a starting point, help remove the bias.
Hi all, 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. This is a brainstorming phase only; please provide suggestions and not *just* negative criticism (both is OK, but please be constructive). Preferably in the form of the section as a YAML compliant data structure, as the below is. I'll be going through the chunks and modifications that people suggest and collating it into a single list and republishing as time permits. Hopefully it's fairly obvious what I've done with the different sections of the old list. There are fewer top level categories, but more sub-categories - and the possibility of sub-sub-categories. Some sections I'm not so in touch with, or wasn't feeling particularly inspired about at the time, that I've left alone. 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. Core Perl language modules and extensions: - internal packages - language mutations - Perl 6-like features Code development and documentation tools: - Editor extensions - Test suite systems - POD processing - POD for more than just API docs - Control Flow Utilities (callbacks and exceptions etc) 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 String and Text Processing: - Parsing modules - Indexing modules - Searching modules - Natural Language Text Processing - Internationalisation and Localisation Databases, marshalling and persistence: - persistent hashes - structured data marshalling - SQL abstraction frameworks - Object Databases - Object/Relational mappers & hybrids - Prevayler-style storage (antidatabases) Networking - raw communication, including IPC: - Shared memory solutions - Pipes - Sockets - Datagrams - Object Request Broker mechanisms Networking - protocol implementations: - RFC based - other standards based Networking - accessing services: - Mail and Usenet News - XML services - YAML-RPC services Networking - providing services: - Server and Daemon Utilities - Web Services Frameworks: - Apache: - Apache PerlHandler modules - Apache PerlInitHandler modules - Apache PerlAuthenHandler modules - Apache PerlAuthzHandler modules - Apache PerlAccessHandler modules - Apache PerlTypeHandler modules - Apache PerlTransHandler modules (May also include a PerlHandler) - Apache PerlFixupHandler modules - Apache PerlLogHandler modules - Apache PerlChildInitHandler modules - Apache Server Configuration - Apache Database modules - Interfaces and integration with Apache C structures and modules - HTTP Method handler - 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 Networking - administering services: - Watchdog and Monitoring tools - Development and Debug tools - Miscellaneous Apache modules User Interfaces: - Command line interfaces - Configuration files - Interactive character and terminal based UIs - Tk toolkit - Gtk toolkit - WxWindows toolkit - other graphical toolkits Imaging, Images, Multimedia: - Sound manipulation - Image Conversion - Raster Image Manipulation - Vector Image Manipulation - Drawing and Graphing utilities Interfaces to and emulations of other languages: - The XS C interface - XS alternatives - C, C++ - Java - JavaScript / JScript / ECMAScript - ... Platform interface: - File Names - File Handle, Directory Handle and Input/Output Stream Utilities - File Systems interfaces - File Locking - File Archiving - File Compression - File Conversion - Hardware Support: - Generic device APIs, eg modems - Specific Hardware/Device drivers Multiprocessing: - Time-slicing oriented - Threading oriented - Fork() oriented Operating System Support: - UNIX system platform specific modules - UNIX variants - Win32 (MicroSoft Windows) platform specific modules - VMS/OpenVMS platform specific modules - mainframe platforms - Embedded / hand-held platforms Interface Modules to Commercial Software: - ? Misfits and Oddballs: -- Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filter
