A link: http://search.cpan.org/~rsavage/CGI-Uploader/lib/CGI/Uploader.pm

Hi ysth The original module was idiosyncratically written and badly documented, and contained various hard-coded decisions. Vast changes were made, based on what I wanted the module to do, compared to what it used to do. The list of changes is not so important, actually. What's important now is to study the new docs and decide if the module does in fact provide a user-friendly upload mechanism.

"Vast changes were made, based on what I wanted the module to do, compared to what it used to do. The list of changes is not so important, actually."

While I agree that it's useful for people to see if your interface is user friendly, to say that the list of changes isn't important seems to fly in the face of everyone using the original module doesn't it? If they're happy with the old module, why should they change without seeing the list of changes you've made?

---

To disagree, one doesn't have to be disagreeable - Barry Goldwater

Thanks your interest in this. I'm curious about the decision to move the imaging code into the core. Uploading could be about a lot of other transformations besides image resizing, and the old design of handing image transformations through a helper module seemed like a reasonable interface:

Before:

gen_files => {       
   'my_thumb' => gen_thumb({ w => 100, h => 100 }),
 }
[download]

 transform => {
    imager  => Imager -> new(),
    options => {xpixels => 400, ypixels => 500},
}
[download]

Hi Mark. Actually, I'm very uneasy about embedding such restricted transformation logic in the module. The feedback has confirmed my suspicions that that part needs to be re-implemented. I was a good idea to call this one 2.90_01 and not 3.00 :-). Cheers