RFC: Name for new modules (RandomJungle::)
resending from a gmail account after failed attempts from a yahoo account - apologies for duplicate postings if the first ones eventually come through) Hi, I developed a series of modules that provide users with the ability to post-process and manipulate the output of the Random Jungle program ( http://randomjungle.sourceforge.net/). The proposed name of each module, as well as a brief synopsis, is included below. Please let me know if more information is desired. I would appreciate input on the selection of names. At last check, there was nothing on CPAN related to Random Jungle. Thanks, Bob There are 7 modules in this distribution, 4 of which provide low-level access to files and 3 of which are intended to be used by client programs. Modules to access RJ data files: RandomJungle::File::XML - Low level access to the data in the RandomJungle XML output file RandomJungle::File::RAW - Low level access to the data in the RandomJungle RAW input file RandomJungle::File::OOB - Low level access to the data in the RandomJungle OOB output file RandomJungle::File::DB - Low level access to the data in the RandomJungle DB file (used to consolidate data from the XML, RAW, and OOB files and provides query methods) Modules to provide a user-centric interface to RJ data: RandomJungle::Jungle - Consolidated interface for Random Jungle input and output data (from the perspective of the entire jungle) RandomJungle::Tree - A Random Jungle classification tree (trees make up the jungle) RandomJungle::Tree::Node - A simple representation of a node in a RandomJungle::Tree
Re: Names and ideas for new modules
cr...@animalhead.com wrote: Someone got excited when I mentioned and posted some WPAD code here a week or two ago, so it may be worthwhile to post it as a module. The second name should probably be WPAD, but what category does it belong in? HTTP::WPAD? IP::WPAD? Proxy::WPAD? Module::WPAD? Net::WPAD? cheers, Aldo
Re: Getting co-maint for new modules in a package
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], Chris Dolan [EMAIL PROTECTED] wrote: Is there an easy solution to getting co-maint on all modules in a distro? Is it just something we need to remember to do, or is there an automatic solution somewhere? At PAUSE we can set up a mailing list user (it's not really a mailing list) for Perl::Critic. Anyone we add to that list can assign co-maintainer permissions. See the guide I made for the Parrot people: http://search.cpan.org/~pmic/parrot-0.7.1/docs/project/pause_guide.pod
Getting co-maint for new modules in a package
The Perl::Critic team has a small but persistent problem with PAUSE. We frequently add new policy modules to the distro. When we do so, the person who does the release gets ownership of that namespace. We have three co-maintainers who do releases, so reminding each other to grant co-maint on the new modules is becoming an unwelcome ritual before handing off the release baton. Is there an easy solution to getting co-maint on all modules in a distro? Is it just something we need to remember to do, or is there an automatic solution somewhere? Chris
Re: Getting co-maint for new modules in a package
Everybody's a critic... (sorry, couldn't resist) On Sat, Oct 11, 2008 at 1:49 PM, Chris Dolan [EMAIL PROTECTED] wrote: The Perl::Critic team has a small but persistent problem with PAUSE. We frequently add new policy modules to the distro. When we do so, the person who does the release gets ownership of that namespace. We have three co-maintainers who do releases, so reminding each other to grant co-maint on the new modules is becoming an unwelcome ritual before handing off the release baton. Is there an easy solution to getting co-maint on all modules in a distro? Is it just something we need to remember to do, or is there an automatic solution somewhere? Chris
New Modules: WWW::Authen::Simple, DBIx::PDlib
The modules WWW::Authen::Simple and DBIx::PDlib implement things that are very similar to a plethora of alternitive modules out there (which is why I'm asking about them both in one thread). WWW::Authen::Simple implements an easy to use OO cookie based authentication with a database backend. It relys only on CGI.pm and Digest::MD5. DBIx::PDlib (bad name) provides an easy to use OO abstraction to DBI, requiring only DBI. The existing modules that are out there can do the job, each with their own strengths and weaknesses. They just didn't fit me, so I wrote my own (DBIx::PDlib even borrows some features from some of the others). I know they can be useful to others, they've been passed around to a handful of people who ended up using them over the other choices, but I don't know what the appropriate thing to do with them is. I'd like to upload them to CPAN, but I know I'll get the why not just use Some::Existing::ModuleX?, and please don't polute CPAN comments... so is it worth considering yet another way to do things? or should I just keep them to myself? If you want to look at them, I've temporarily put them up at: http://www.purifieddata.net/pm/ (note: WWW::Authen::Simple is sorely lacking documentation) Thanks, -- Josh I.
Re: New modules
* Oliver White oliver.white at blibbleblobble.co.uk [2003-11-12 20:22]: As a first step, I was considering adding a module to read GSHHS data [a binary format for coastline data] and give it a name something like Geo::GSHHS. More info at the site: http://www.soest.hawaii.edu/wessel/gshhs/gshhs.html You could petition the namespace maintainers for a GIS top level, especially if you forsee producing a number of modules. Is this the right place to ask? Yes. (darren) -- So far as a man thinks, he is free. pgp0.pgp Description: PGP signature
Re: New modules
On Wed, Nov 12, 2003 at 08:22:01PM +, Oliver White wrote: As a first step, I was considering adding a module to read GSHHS data [a binary format for coastline data] and give it a name something like Geo::GSHHS. More info at the site: http://www.soest.hawaii.edu/wessel/gshhs/gshhs.html Sounds like a good idea to me, considering that Geo::ShapeFile is already established. //Ed
Re: New modules
On Wed, 12 Nov 2003 20:22:01 +, Oliver White wrote: Hiya. I'm about to start work on some GIS programming in Perl, and will likely end up with a few modules that might usefully go onto CPAN. From what I've read on the FAQs though, it seems like a bit of a minefield to choose a name that someone else doesn't want, See below. and to find out if anyone's already working in the same area. I did some searches on the CPAN website for likely modules, while the documentation suggests I ask on some mailing lists, which I presume includes this one? Yes, and possibly a post on comp.lang.perl.modules. But this list is where the issues will be argued back and forth. As a first step, I was considering adding a module to read GSHHS data [a binary format for coastline data] and give it a name something like Geo::GSHHS. More info at the site: http://www.soest.hawaii.edu/wessel/gshhs/gshhs.html To help us understand the problem better, could you spell out 'GSHHS' and 'GIS'? Any comments? Is this the right place to ask? Yes, this is *definitely* the right place to ask. Is there already code somewhere that does it? Would anyone be offended if I wrote the module? No one will take offense if you write the module, but (as you imply above) our fellow module-authors are picky about the names of new modules. One consideration here: In the last week or so, there has been discussion on this list re the general appropriateness of the 'Geo' namespace. It seems to be doing double-duty for both 'Geometry' and 'Geography' and some are advocating putting geographic modules in the 'Geography' namespace. I'm not sure where that discussion ended up; check the archives or Google it. But you might want to wait for that discussion to resolve before finalizing your own module's name. Jim Keenan
