upload component: jQuery Uploader vs. swfupload

[Eli Cochran]

Hi,
Gilles van den Hoven has released his jQuery Uploader. Originally  
planned as part of jQuery UI, it appears to been cut loose and  
released on it's own.

This version actually works and I've played with with it, thought  
about it and now I want to say why I don't think that we should use  
it. My plan is to stick with the swfupload version that I'm currently  
working with.

You can look at the plug-in in action here: http://uploader.webunity.nl/
The documentation for it is here: http://docs.jquery.com/UI/Uploader

and for reference information on swfupload can be found here: http:// 
swfupload.org/

If you are going to review, don't get too caught up in the UI. The  
wonderful thing about this small-swf/large-javascript approach is  
that the UI can look like just about anything. Focus on functionality.

But even functionality is not my reason for rejecting the jQuery  
version. The jQuery version is good, it has a very similar feature  
set as the swfupload version. In fact, the author of jQuery upload  
says that his version is based on an earlier version of the swfupload  
component. And as far as I can tell the swf part is almost identical.

So my reasoning is this, the swfupload project seems to have a  
dedicated community around it, five programmers, and a lot of  
interest. They've been putting out regular updates. (The jQuery  
version hadn't seen any activity for a few months until today.) The  
code is solid and very full featured. It is framework agnostic --  
stand-alone but with a very well define API that we can build off of  
using whatever framework floats our boat.

And by sticking with a very active project, my hope is that we will  
benefit from the improvements that they make and hopefully we can  
offer something back. Finally, it was a very innovative approach, one  
that fits perfectly with our needs. I don't know that Gilles would  
have come up with it on his own (I wouldn't have). I'd like to stick  
with the originators of this idea and not follow a knock-off just  
because the knock-off is written in our framework of choice.

That's all,
Eli



. . . . . . . . . . .  .  .   .    .      .         .              .     
                  .

Eli Cochran
user interaction developer
ETS, UC Berkeley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080212/d7201a2d/attachment.html>