On Mon, 8 Nov 2004, Jorg Heymans wrote:
Luigi Bai wrote:Point taken, but how many different implementations does a multipartparser really need ? Commons-fileupload is RFC 1867 compliant, has disk and memory based storage and is a "known and trusted" commons library.Hi,
I'd like to point out that the Multipart support in Cocoon is one of the few things that isn't pluggable or replaceable. I'd like it to be possible to configure web.xml/CocoonServlet to take a class name that implements some MultipartParser interface, and keep Part as an interface (perhaps letting it evolve as different implementations are available).
Not many different ones are "needed". However, the current one is buggy, and it would have been much easier to replace for an end-user if it werent' so heavily embedded into the Servlet. If some problem turns up in commons-upload, or in your code, as a non-commit level end user I'm back in the same boat; I have to rewrite CocoonServlet to just fix it or hack it out. I *could* then make a PATCH to fix it, which would be forever ignored in Bugzilla. :-)
I find it hard to believe that we just saw Avalon/Excalibur/etc. implode, Carsten is rewriting core to get around it - I don't think it's reasonable to hard code another dependency at the class level. Since you're rewriting it anyway, how hard is it to abstract one level out?
True, but we're talking about 5 isolated classes that deal with file uploads, nothing more.
Keeping the integration at the level of Interface means we don't run into the same kind of rigamarole that is going on with ECM etc.
IMHO : YAGNI
Well, it's your code.
