Re: pure perl Zlib
On Mon, 16 Feb 2004, A. Pagaltzis wrote: * Sam Vilain [EMAIL PROTECTED] [2004-02-15 22:44]: ...but it doesn't use Zlib! :) Compress::Gzip? * Nicholas Clark [EMAIL PROTECTED] [2004-02-15 22:53]: But it doesn't compress. Compress:Gunzip? Uncompress::Gzip (Neither really meant as serious suggestions) Problem is that it's an emulation of bits of Compress::Zlib's interface, so I feel that a clue should be in the name. As should the bit that it's pure perl, as otherwise it's like huh, why another front end to some C code? Then maybe it needs to mention that it's an emulation, but besides Compress::Zlib::Emulated anything I come up with needs at least three words, and those are still incomplete. Maybe Compress::Gunzip::ZlibAPI? I've used other pure perl modules that implemented some other API, so I looked up a handful of them, history being the best teacher. Net::SSH::Perl (pure perl Net::SSH) Apache::FakeSSI (subclass of Apache::SSI using pure perl instead of Apache subrequests to implement server side includes) DBD::PgPP (pure perl postgresql dbd driver) DBD::mysqlPP (pure perl mysql dbd driver) MIME::Base64::Perl (pure perl MIME::Base64) Crypt::Des_PP (pure perl implementation of Crypt::Des) Crypt::Blowfish_PP (pure perl implementation of Crypt::Blowfish) (bunch of other Crypt::*_PP modules) I don't care much for Apache::FakeSSI name, but I didn't look into what it does, so it might just be appropriate. The others either append PP to the name of the module it is reimplementing, or ::Perl. I'd like to see it as Compress::Zlib::Perl or Compress::Zlib_PP, as that's what I've come to expect. Which of those is correct, I don't know. I personally prefer Compress::Zlib_PP, as it is a completely new name tree, but that's just me. For example, if either of Compress::Zlib or Compress::Zlib::Perl had other modules included with them, there is a slightly higher chance of a name collision (though I doubt Compress::Zlib would use a ::Perl subdirectory). I don't think the other suggested names are appropriate, as they all deal with Gzip and Gunzip, which Archive::Zlib(_PP|::Perl) doesn't appear to implement. (other names mentioned: Compress::Gunzip::ZlibAPI, Compress:Gunzip, Uncompress::Gzip, Compress::Gzip) -- Josh I.
Re: Finding the module you want (was: New module Mail::SendEasy)
On Sun, Feb 15, 2004 at 11:57:15PM +0100, A. Pagaltzis wrote: * Rocco Caputo [EMAIL PROTECTED] [2004-02-12 11:29]: Conveniently, I've written exactly the thing that provides the features I need, in a way that's most convenient for my purpose. Everything else pales by comparison, otherwise I would not have written it. Here, let me show you. Are you picking a bone with someone particular? :-) Where's the challenge in that?! I'm picking bones with lots of people! ;) -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
Hi, I think an interesting angle, first to get an idea of what the problem is, and later (hopefully!) to see if we have improved the situation, is to put ourselves in the position of a Perl programer that doesn't know the community, maybe doesn't even know that CPAN exists. Her first reflex would probably to google for perl + keyword. So let's see what she'd get for some sample keywords: perl xml perl-xml mailing list archive perl-xml FAQ perl date perl-date-time cvs.sourceforge.net/cgi-bin/ viewcvs.cgi/perl-date-time/ perl time nothing really interesting perl database recent useless article dbi.perl.org perl oracle nothing really interesting perl mysql nothing really interesting perl cgi Matt's Script Archive ??? perl mail an old article http://alma.ch/perl/mail.html perl csv 2cd hit: a 2001 page about a non-CPAN CVS module http://rath.ca/Misc/Perl_CSV/index.shtml Not great hey? (At least the Perl-XML folks got it right, props to Grant McLean!). After looking at the results, it seems to me that one of the problems here is that you can't really link to CPAN: there is no single URL for the latest docs of a module, so they are never properly indexed by search engines.A simple step would be to have a single, static, doc page for each module, generated for each new release, but with a stable and easy to remember URL. Then we can start refering and linking to it, and Google can perform its role and we shall be happy for ever after (or at least we can find something else to do with our time ;--). Generating the doc (from the POD) for each module (with a link to the tarfile or to the CPAN search page for the lates release of the module), and putting it on CPAN in something like cpan.org/docs/module name. If size is a problem for mirrors, then a shorter version, with just links to the docs, would work, maybe the search.cpan.org results for example: http://search.cpan.org/~timb/DBI-1.40/ could be statically generated to just http://cpan.org/docs/DBI/index.html Does this make sense? -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: pure perl Zlib
On Sun, Feb 15, 2004 at 09:51:18PM +, Nicholas Clark wrote: On Mon, Feb 16, 2004 at 10:43:27AM +1300, Sam Vilain wrote: On Mon, 16 Feb 2004 10:19, Nicholas Clark wrote; Autrijus suggested Compress::Zlib::PurePerl, which I think is reasonable. ...but it doesn't use Zlib! :) Compress::Gzip? But it doesn't compress. Compress:Gunzip? Uncompress::Gzip (Neither really meant as serious suggestions) Problem is that it's an emulation of bits of Compress::Zlib's interface, so I feel that a clue should be in the name. As should the bit that it's pure perl, as otherwise it's like huh, why another front end to some C code? I agree. Compress::Zlib::PurePerl seems okay, but there's really no need for the extra level. Compress::ZlibPP would be fine. (It seems that 'PP' is becoming a convention for 'pure perl'.) Sure, it doesn't compress today, but it might in future. (Meanwhile it could emulate the whole API and just return errors when interfaces it doesn't support are called.) Tim.
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
Michel Rodriguez [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Generating the doc (from the POD) for each module (with a link to the tarfile or to the CPAN search page for the lates release of the module), and putting it on CPAN in something like cpan.org/docs/module name. Does this make sense? Yes and that's what search.cpan.org already does. Cheers, Nadim.
Re: [RFC] Text-Balanced 1.96 proposed interface changes: return failure in list context
Vagn Johansen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] How do you avoid breaking old programs when the interface changes? You don't. IMHO it's the users responsibility to check for what version they are using not the module author. With Module Build you can ask for a specific version. It's debilitating for a module author to not be able to change interface because someone is using the module. I've seen (and couldn't find it again) some discussion about having multiple versions of a module installed (link someone?) Cheers, Nadim.
Re: [RFC] Text-Balanced 1.96 proposed interface changes: return failure in list context
[EMAIL PROTECTED] (Khemir Nadim) writes: Vagn Johansen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] How do you avoid breaking old programs when the interface changes? You don't. IMHO it's the users responsibility to check for what version they are using not the module author. It is, however, polite for the module author to inform the user that there's been a change. Imagine I change the interface of module X. You have some code which uses program X and it works fine. Now you write some completely different code that depends on module Z, so you use CPANPLUS or whatever to install module Z. Module Z depends on module Y, so CPANPLUS installs that too, and module Y depends on a new version of module X, so CPANPLUS installs that one as well. Boom, action at a distance. As a result of using a completely unrelated module, you've just broken a load of old code. This is why I tend to do something like this in Makefile.PL: print WARNING: This new major release is incompatible with previous\n; print releases. Please check any code which uses this module.\n; print Press enter to continue.\n; ; -- I think of AI as the study of programming situations where either don't know what you want, or don't know how to get it. - Sean Burke
Re: OK, so we've decided that the right modules are too hard to find.
Sam Vilain [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] - encourage curators to step forward, or groups of curators, for each category; possibly even create mailing lists for people with a general interest in the technology in that category; to field questions about naming for new modules to fit into each category. These curators must have the power to update the contents of the relevant portions of the www.cpan.org site. Hi all, Everything that was said in this thread was very interresting and I, too, belive things should get better and I encourage those that want to do things _now_. I see few problems with CPAN, you might find them directly related to the need for curators: - Any one can start whatever hierarchy - Anyone can load whatever piece of code to CPAN, good or bad - Documentation level is a catastrophy, check how many readme are those generated by h2xs - The document about how to use CPAN is not clear enough or I haven't found the right one yet - 25 versions of the same module do no make it easy to look around in CPAN - Authors don't answer or have given up on maintaining there modules - The same day, the same module can be uploaded to CPAN multiple times I mirror CPAN at home and I check for new modules everyday. Guess how many times I think what the Hell is this for??? Far from me the idea to refuse uploading of modules to CPAN but 3 years from now, we'll have a useless module heap. If there is a need for curators, I believe it does, then those should be given a mandat and power to apply it or it will be useless. They must be able to say to a module author: Sorry but this is not the quality level we expect, write some documentation and come back later for your upload. This is exactly what is done for moderated mailling lists. The net result would be (IMO): - No half baked idea, modules on CPAN (could be a good idea to go through what we have today in CPAN and throw away things) - Better quality in the documentation and test (hmm, I'd have to work on my own modules too) - More people involved in this mailling list (which has less than 20 active users) since it would be the way in to CPAN Around 15 new, or updates, modules are uploaded to CPAN everyday. This might sound drastic but it is not as bad as it sounds, I would have appreciated if someone said 'No' to something I write and that is not good enough for the community. This is not for discouraging module authors but, on the contrary, make them feel that their work is appreciated and that they must commit themselves to generate something good enough. Moderators rights should be: - Create new hierarchy roots - Refuse a module name - Refuse a module because its quality is too low - Refuse a module because of lack of documentation or tests or examples (or VERSION!!!) - Give maintenance rights - Try to merge modules by asking module authors to co-operate - Write public review or accept public reviews - Coordinate with module testers - etc ... I am whilling to have my modules filtered, I hope other do too. I'll also help if I can. Cheers, Nadim. PS: PPM modules vs plain module problems should be fixed too.
Re: OK, so we've decided that the right modules are too hard to find.
[EMAIL PROTECTED] (Khemir Nadim) writes: Everything that was said in this thread was very interresting and I, too, belive things should get better and I encourage those that want to do things _now_. None of these ideas are new. - Any one can start whatever hierarchy This is not a problem, now we have search.cpan.org. - Anyone can load whatever piece of code to CPAN, good or bad I don't agree that this is a problem. - Documentation level is a catastrophy, check how many readme are those generated by h2xs But the generation was added to h2xs because people weren't putting in READMEs, and so an autogenerated one is better than nothing! - The document about how to use CPAN is not clear enough or I haven't found the right one yet You haven't found the right one yet. - 25 versions of the same module do no make it easy to look around in CPAN This is not a problem now we have search.cpan.org. - Authors don't answer or have given up on maintaining there modules THEY ARE VOLUNTEERS. - The same day, the same module can be uploaded to CPAN multiple times Yes, module authors can fix bugs quickly. How terrible! Far from me the idea to refuse uploading of modules to CPAN but 3 years from now, we'll have a useless module heap. If there is a need for curators, I believe it does, then those should be given a mandat and power to apply it or it will be useless. *We have been through this*. Innumerable times. Still nothing happened. The people most likely to act as curators got together (as they do periodically) and decided that better metadata would be the best short-term goal. I'll try and get some of them to write up the latest set of proposals. -- 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: OK, so we've decided that the right modules are too hard to f ind.
Title: RE: OK, so we've decided that the right modules are too hard to find. [EMAIL PROTECTED] (Elizabeth Mattijsen) writes: I've released about 30 modules in the past 1.5 years. I _never_ bothered to try to register. I guess that means something. Likewise. (although slightly more than 30 ;) I just don't see the point of the modules list, especially now we have search.cpan.org. Afaik the only real reason for the modules list is to prevent people from accidentally installing a module that is released under a known name, but by an unknown author. So if I release Email::Simple 1.4 no one using CPAN.pm to install it will end up with my version, they will always end up with your version. This does something towards preventing attacks on the community by embedding hostile code in the install scripts and then uploading them under trusted names. Its actually very annoying because the hand over and ownership management on CPAN isn't that hot (and doesnt synchronize with RT fwict), so if you take over maintenance of a module and it hasnt been properly handed over the code can only be found via the website or via an 'ls' on the authors directory. Which brings me back to the web site. From what I can tell this security measure has not been implemented on the web site. There is nothing on a page to tell you if the module you are looking at is actually released by the correct person. So presumably if I upload DBI 1.42 with a trojan to wipe the hard drive I bet that just from web downloads alone ill end up with some victims. So not only does search.cpan.org NOT make the modulelist redundant, it in fact should should be modified to ensure that module list information is presented to the user. At very least when viewing a module the page should very clearly state that the displyed module is not released by the approved author/owener of the namespace. (Assuming of course that this is the case.) IMO the module registration process is broken from a management point of view (ive stated this in private correspondence to the site owners and CPAN folks) but the module registration process is definately not redundant or unneeded. It badly needs to be reformed and reworked though. Just my (not so) humble $0.02. Yves
RE: OK, so we've decided that the right modules are too hard to f ind.
Title: RE: OK, so we've decided that the right modules are too hard to f ind. [EMAIL PROTECTED] (Yves Orton) writes: Afaik the only real reason for the modules list is to prevent people from accidentally installing a module that is released under a known name, but by an unknown author. So if I release Email::Simple 1.4 no one using CPAN.pm to install it will end up with my version, they will always end up with your version. You're confusing the module list with the module list. :) Shoot. Your right. I keep confusing the module list with the module list. Its a horrible habbit. :-) 02packages.details.txt.gz, generated by PAUSE, does what you're talking about. The module list (00modlist.long.html) is what we were talking about, since that is the one you have to register for. And I still think that 00modlist.long.html is now irrelevant. Ok, now I get you. Yeah you may have a point there. But I still think my point about the site being an security vulnerability is valid. CPAN.pm provides a modest level of protection against this type of thing, but the site none. I hope it doesnt take an exploit for some logic to be added to the pages to state that the release is not by the official author. Yves
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
On 16 Feb 2004, Ask Bjoern Hansen wrote: [EMAIL PROTECTED] (Michel Rodriguez) writes: [...] If size is a problem for mirrors, then a shorter version, with just links to the docs, would work, maybe the search.cpan.org results for example: http://search.cpan.org/~timb/DBI-1.40/ could be statically generated to just http://cpan.org/docs/DBI/index.html http://search.cpan.org/dist/DBI/ works. Why should it go on www.cpan.org rather than just be on search.cpan.org? OK, I stand corrected. Then the problem is why don't those pages show up higher when you search on google? They come back fast enough, I suppose they are static, can anyone confirm this? There doesn't seem to be a robots.txt preventing them to be spidered, so they should be indexed. I guess it becomes a social (for lack of a better term) instead of a technical issue: this is what we should link to when we want to reference a module. The fact that I did not know about those shows first that I am quite dumb, but also that even someone who should know about it, well... doesn't. Should we spread the word (through the FAQ? I can post something on PerlMonks) that this should be the proper way to reference modules? -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
[EMAIL PROTECTED] (Michel Rodriguez) writes: I guess it becomes a social (for lack of a better term) instead of a technical issue: this is what we should link to when we want to reference a module. This is in fact the policy I've been using for perl.com for a while now. -- A word to the wise: a credentials dicksize war is usually a bad idea on the net. (David Parsons in c.o.l.development.system, about coding in C.)
Re: [RFC] Text-Balanced 1.96 proposed interface changes: return failure in list context
David Nicol on 15 Feb 2004 18:31:25 -0600 writes: On Fri, 2004-02-13 at 00:45, David Manura wrote: [ the interface will change! ] I hope you are planning on adding a VERSION subroutine that will not accept requests for old, incompatible versions, while accepting requests for all later versions (which presumably will be bug-fixes and backwards-compatible feature extensions only.) How are interface changes handled on CPAN? How do you avoid breaking old programs when the interface changes? Just curious. -- Vagn Johansen
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
* Michel Rodriguez [EMAIL PROTECTED] [2004-02-16 10:57]: (At least the Perl-XML folks got it right, props to Grant McLean!). You don't put yourself in a particular spot on Google, you just get there by being linked from lots of places. You have zero control over whether and where you appear in the results for a query. there is no single URL for the latest docs of a module, so they are never properly indexed by search engines. Did you try searching for a module name? Go look up, I dunno, Compress::Zlib or something on Google. A simple step would be to have a single, static, doc page for each module, generated for each new release, but with a stable and easy to remember URL. Cf Ask's reply. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: pure perl Zlib
* Tim Bunce [EMAIL PROTECTED] [2004-02-16 11:53]: (Meanwhile it could emulate the whole API and just return errors when interfaces it doesn't support are called.) That's an excellent suggestion and nicely resolves the naming issue as a side effect. Very nice. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: OK, so we've decided that the right modules are too hard to find.
Simon, Can you please give us serious answers. Writting to this list take valuable time from me and from those reading the mails. - Authors don't answer or have given up on maintaining there modules THEY ARE VOLUNTEERS. Please don't shout if it's note to show you're happy. Check the discussion we had about Roman.pm a few weeks ago. My point is not to force anyone to develop anything but that when a module is released and the author can't maintain it, the curators job would be to design a new maintainer. Period. Now, surf to: http://search.cpan.org/recent and check: Haver-Server-0.02 -- Perl extension for blah blah blah You might think it's OK but I don't. Here is an example of what changed from version 0.07 to 0.08 for a module (loaded 10 mn after 0.07) 0.08Sun Feb 16 16:21:00 2004 Fixed MANIFEST for test.pl Everybody makes mistakes. I just would like to help people not do this kind of mistakes. Since I have missed the document, you might be able to point to it instead for telling me that I have missed it. And no, sear.cpan.org isn't a silver bullet though I use it more than cpan.org. Cheers, Nadim. Simon Cozens [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] (Khemir Nadim) writes: Everything that was said in this thread was very interresting and I, too, belive things should get better and I encourage those that want to do things _now_. None of these ideas are new. - Any one can start whatever hierarchy This is not a problem, now we have search.cpan.org. - Anyone can load whatever piece of code to CPAN, good or bad I don't agree that this is a problem. - Documentation level is a catastrophy, check how many readme are those generated by h2xs But the generation was added to h2xs because people weren't putting in READMEs, and so an autogenerated one is better than nothing! - The document about how to use CPAN is not clear enough or I haven't found the right one yet You haven't found the right one yet. - 25 versions of the same module do no make it easy to look around in CPAN This is not a problem now we have search.cpan.org. - Authors don't answer or have given up on maintaining there modules THEY ARE VOLUNTEERS. - The same day, the same module can be uploaded to CPAN multiple times Yes, module authors can fix bugs quickly. How terrible! Far from me the idea to refuse uploading of modules to CPAN but 3 years from now, we'll have a useless module heap. If there is a need for curators, I believe it does, then those should be given a mandat and power to apply it or it will be useless. *We have been through this*. Innumerable times. Still nothing happened. The people most likely to act as curators got together (as they do periodically) and decided that better metadata would be the best short-term goal. I'll try and get some of them to write up the latest set of proposals. -- 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: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
On Mon, Feb 16, 2004 at 10:37:12AM +1300, Sam Vilain wrote: On Mon, 16 Feb 2004 01:32, Tim Bunce wrote; I'd like to see a summary of what those needs of the community are. (Maybe I missed it as I've not been following as closely as I'd have liked. In which case a link to an archived summary would be great.) It's very important to be clear about what the problems actually are. I don't really want to argue this side of things, I think that the problems pretty much speak for themselves. But I hate unspoken consensus, so let me suggest a few from my perspective; this applies to the combined Perl 5 modules list / using search.cpan.org: I'll play devils advocate here and point out some alternative remedies for the problems. By doing so I'm _not_ trying to detract for your suggestion, which I like, I'm just trying to show how existing mechanisms could be improved incrementally. a) searching for modules for a particular task takes a long time and unless you get your key words right, you might not find it at all. Refer the recent Mail::SendEasy thread. Calls for a richer set of categories and cross-links of some kind. (Editorial content alone is basically just more words to a search engine.) b) it is very difficult to find good reviews weighing the pros and cons of similar modules; they exist, but are scattered. CPAN ratings was a nice idea, but has too many First Post! style reviews to be useful in its current form IMHO. Argues for moderation of reviews and a minimum review length. A was this review helpful mechanism would also help to bring better reviews to teh top. Also the search.cpan.org should not just show the overall rating, it should show the underlying three individual ratings (docs, interface, ease of use). c) it is nearly impossible to tell which modules are the wisest choices from a community size point of view; using modules that are more likely to fall out of maintenance is easy to do. Argues for more stats. I think useful *relative* download stats could be extracted from a sample of CPAN sites. Also search.cpan.org could provide relative page-*view* stats for modules. d) some great modules are not registered (I am referring of course to such masterpieces as Pixie, Heritable::Types, Maptastic :), Spiffy, Autodia, Want ... and those are just the ones missing in my bag of tricks) Argues for fixing the registration process. Originally the Module List had two goals: 1: to help people find perl modules for a particular task. 2: to provide a second-tier of modules above the 'anarchy' of people uploading half-baked ideas with half-baked names. Honourable goals, which it solved adequately for a period of time, and full credit where it is due. But now let's look at where we are. We've got masses of modules, truckloads of categories and thousands of contributors. This task cannot be left in the hands of a handful of hackers, no matter how much awe they inspire, they probably still have lives and day jobs ;) The registration process can, and should, be automatic for any modules for which no one objects. You'd apply and RT would automatically register if no one commented on the application. I will maintain that the current format, or even simply adding some more fields to the database is *not* enough information to give uninformed people looking for a module the information to make an informed decision. It is my gut feeling that only editorial content, managed by people who are experts in the field, will truly perform this task - and that to gain maximum support, that it should be included in the content mirrored along with the rest of cpan.org. I agree that comparative editorial reviews would be very valuable for Goal 1 above. I wouldn't address Goal 2 effecively at all. I think we're mature enough as a community to be able to produce this content without it disolving into flamewars or being too one-sided. In particular, I really think that as little red tape should be applied to this system as possible. Let's just set up a few CVS / subversion accounts, to edit content that is autopublishing to the www.cpan.org site, with a few disclaimers chucked on the bottom. LARTing the naive and troublesome as appropriate. I agree. This all seems very similar to the DMOZ.org project that maintains reviews of millions of web sites: 6,095,104 sites - 61,277 editors - 551,043 categories That's a mature and very sucessful model (used by google directory etc) that's well worth learning from. The text file is out of date. The underlying database isn't: [...] Please work with the PAUSE system, and Andreas and myself, to enhance what already exists (which includes a UI for module authors to pick which category they want the module in). I'd be honoured to. I think that the plan you propose would be an excellent
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
On Mon, 16 Feb 2004, A. Pagaltzis wrote: * Michel Rodriguez [EMAIL PROTECTED] [2004-02-16 10:57]: (At least the Perl-XML folks got it right, props to Grant McLean!). You don't put yourself in a particular spot on Google, you just get there by being linked from lots of places. You have zero control over whether and where you appear in the results for a query. there is no single URL for the latest docs of a module, so they are never properly indexed by search engines. Did you try searching for a module name? Go look up, I dunno, Compress::Zlib or something on Google. The 2 things are linked: if people know that there is single, static page to link to when articles, web pages, posts on perlmonks of messages in mewsgroups or in archived mailing lists, then this page will rise through Google rankings and come up when people search for perl and a relevant term. As for finding Compress::Zlib... If you already know what you are looking for, then of course you will find it. In this case a naive user would be lucky though, as 'perl+gzip' returns a link to the doc for Nick Clark's PerlIO-gzip-0.15 (which doesn't have any link to download the module itself, drat!). I think having a convention to link to http://search.cpan.org/dist/* would give these pages a chance to be more visible for programers who don't know about CPAN, or who are overwhelmed by it. The remaining problem I see is that the dist/ pages contain only the one-line description for the module, so there is a risk there that some useful keywords might be missing (Compress::Zlib mentions the zlib library but not gzip for example). Improvement ideas welcome... -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
* Michel Rodriguez [EMAIL PROTECTED] [2004-02-16 13:43]: Then the problem is why don't those pages show up higher when you search on google? They come back fast enough, I suppose they are static, can anyone confirm this? Again this is not a factor. All you have to do is make sure you don't use query parameters, as Google won't index a lot of different combinations. It will however index dynamic pages if you use PATH_INFO to pass parameters, not knowing any better. The WLUG Wiki http://www.wlug.org.nz/ (which has a rather high pagerank) is a good example. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: OK, so we've decided that the right modules are too hard to find.
On Mon, 16 Feb 2004, khemir nadim wrote: Please don't shout if it's note to show you're happy. Check the discussion we had about Roman.pm a few weeks ago. My point is not to force anyone to develop anything but that when a module is released and the author can't maintain it, the curators job would be to design a new maintainer. Period. Going back to Roman.pm (I was on vacation when you first posted, hence no answer at the time), if a PAUSE admin wants the email of the original creator, (he seems a bit paranoiac about letting it displayed in the wwwild), I have it, so he can gain the rights to maintain his own module ;--) -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
On Tue, 17 Feb 2004 02:53, A. Pagaltzis wrote; (At least the Perl-XML folks got it right, props to Grant McLean!). You don't put yourself in a particular spot on Google, you just get there by being linked from lots of places. You have zero control over whether and where you appear in the results for a query. That's not entirely true. It is by design that pages - especially off-site pages that contain text content on a relevant subject, and linking to an article will increase the ranking of the target article in Google. AIUI, this was Google's flagship feature in the early days. No doubt the others have since followed suit to varying degrees. In face, the better search engine optimiser companies out there work (as well as doing easy things like making meta information appropriate) by producing a series of micro-sites that have a page or two of relevant information, then link to the target site, and to each other. So, editorial content may have the desired effect of raising search engine rankings; especially the more they are linked to as a primary source of this information. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) No man can prove upon awakening that he is the man who he thinks went to bed the night before, or that anything that he recollects is anything other than a convincing dream. -- Richard Buckminster Fuller
Re: [RFC] Text-Balanced 1.96 proposed interface changes: return failure in list context
Simon Cozens wrote: [EMAIL PROTECTED] (Khemir Nadim) writes: When I get the message above, I'll hit the return key faster than light There's not really much a module author can to do help a user like that. yes there is, it's the custom VERSION subroutine. Your legacy program dies with the error message until it is edited, after the module upgrade.
Re: [RFC] Text-Balanced 1.96 proposed interface changes: return failure in list context
Vagn Johansen wrote: How are interface changes handled on CPAN? They're not. I'm trying to promote a pradigm of including a VERSION subroutine that will croak (or at least die) when you ask for a non-forwards-compat. version. In theory, you change the name when you change the itnerface, instead of merely updating the version number. How do you avoid breaking old programs when the interface changes? Issue a new module name with the new interface, and maintain both versions for bugs.
