Re: CGI::Uploader (was: CGI::FileManager)

[Andy Wardley]

Mark Stosberg wrote:
 I think I want to make some slight tweaks to the API, but it's about
 ready for 1.0.  It's built around my own common usage: Uploading images
 and storing meta data in a database. However, it works fine for non
 images as well.

I think this module should be called CGI::Image::Upload, or perhaps
even CGI::Application::Image::Upload.

It's not a generic module for uploading images (it makes assumptions about
the fact that you're using DBI for example).  And there's certainly far
too much image specific functionality to warrant such a general name.
The facility to create image thumbnails, for example, certainly doesn't
belong in a generic CGI::Upload module.

It's really just a module that implements your particular image upload 
web application, IMHO.  There's nothing wrong with that, and there's 
plenty of room on CPAN for it, if you want to upload it.  But please 
give it a name that reflects what it actually does.

 BTW, I looked at CGI::Upload too and don't currently recommend it. Check out
 the bug reports currently filed against it.

CGI::Upload looks like it fits the bill perfectly to me.  It does one 
thing and from what I can tell, it does it well.

I can see two minor bugs that require little more than a line or two of
changes to fix them, and one feature request which includes code.  Are
there some other bugs I'm missing?

Personally I would rather see efforts made on fixing these bugs than 
releasing a new module with an almost identical name that does something 
less useful for most of the people, most of the time.  

A

Re: Reshaping the modules list: the current situation

[Andy Wardley]

Sam Vilain wrote:
 11) String Processing, Language Text Processing, Parsing and Searching
 * Stemming algorithms
 * Natural Languages
 * Specific Natural Languages

+ * Templating modules

A

Re: Version Numbers

[Andy Wardley]

David Wheeler wrote:
 So, what do people like or prefer, and why? Is there a consensus on 
 this? If so, what is it?

I manually give the main module in a distribution a real version number 
such as 2.00, 2.01, and so on.  Naturally this changes on every release.

All the other modules in a distribution have a version number built 
automatically from the CVS revision.  This changes only when the source 
file changes.

  $VERSION = sprintf(%d.%02d, q$Revision: 1.23$ =~ /(\d+)\.(\d+)/);

I think it's a good idea for every module to have a version number, even
if they are very rarely used.  If possible, don't change version numbers
of sub-modules between distributions unless they have changed.

That way it is easy to tell at a glance that versions 2.10 and 2.11 of
the Foo::Bar distribution, both use the same version 3.14 of the 
Foo::Bar::Magic::Helper module, for example, without having to mess 
around with diff.

A

Re: RFC Text::UberText

[Andy Wardley]

Chris Josephes wrote:
 2. Text::MetaText
[...]
 ...but it has a very limited command set with no means
 to allow for expansion.

 and has been superceded by the Template Toolkit.


A