cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <geoff.how...@gmail.com>
Subject Re: [rfc] commons fileupload replacement
Date Mon, 08 Nov 2004 18:44:15 GMT
On Mon, 8 Nov 2004 08:20:56 -0600 (CST), Luigi Bai
<lpb+cocoon@focalpoint.com> wrote:
> 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).

Some historical/background points (with the caveat that some changes
have happened due to CForms that I have not paid full attention to):
- We also have tried to avoid anti-patterns like "over
componentization" i.e., making things pluggable that really don't need
to be, which was probably judged to be the case here (though see
below).
- There were other grander plans for request handling.  In particular,
see the "Pluggable Request Factories" of Stefano's RT here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106131747919501&w=2
- You'll notice a third point in the RT above: our "pluggable" problem
extends beyond multipart uploads.  It includes things like WebDAV and
SOAP.

> 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.

True, although another major lesson learned from ECM was that external
communities can also let you down.  The last time I monitored the
commons list, I didn't get warm fuzzies about the politics and health
there, for what that's worth.

> By the way, I'm not clear on why Multipart support can't be implemented as
> an Action? If it's an Action, then it's clearly pluggable, and all this
> goes away. Why is it so early in the process, hard coded in CocoonServlet?

- Actions were a muddy concept that have been or can be at least
partially if not fully replaced by other items.
- Why so early in the process is another good question.  Two reasons I
remember are:
1) Cocoon is not only a CocoonServlet but also runs in different
environments (Command Line for example) where multipart requests do
not have exact parallel if they exist at all.  We have tried to avoid
dependencies on Servlet specific APIs in part due to this issue.
Combined with the fact that Cocoon's uri abstraction (all uris are
mapped to the CocoonServlet, making total control in sitemap possible)
makes it possible that relying on Commons upload may turn out to be a
bad idea in the end: they do not have the same complexity of concerns.
 In fact, they've had some recent refactoring there to accomodate
portlet environments.  If someone can give an analysis of whether this
helps us or hurts us with respect to our complex needs, that would be
a big plus.
2) The cocoon framework as many frameworks pre-parses the request to
make all parameters available to the pipeline semantics.  The plan of
adaptRequest was to allow this to take place for most parameters up
front, but the multipart bits later.  The work to do this was never
done.

Any patch that addresses all these concerns would probably get some
good attention.

Short of that, a patch that provides backwards compatibility by
wrapping the commons library is next best in my opinion.  Short of
full pluggable request adaptors, encapsulation is as good as
configurability in this case IMO.  In this case, I think people will
be fine with one solution for the project, as long as it's easy to rip
out and replace if necessary.

A third option:  The entire project at Commons as far as I can see is
about 15 classes and hasn't had a release in almost a year and a half.
 (I'm guessing this is because the RFC for file uploads has not
changed and probably isn't expected to?).  In this case, I think it's
entirely reasonable to just fix our existing implementation rather
than depend on another project.

Earlier someone noted the comment in the code about multipart/mixed. 
I am not an expert here, but when I looked into this some time ago, it
was not supported by browsers.  We do support multiple files per form
using multiple input elements, so full conformance with the spec would
be academic.  Am I wrong here?

Geoff

> On Mon, 8 Nov 2004, Jorg Heymans wrote:
> 
> >>
> >> Is posible to add support for both at the same time? If this is possible,
> >> then we can add it in 2.1.6 and deprecate the old approach.
> >
> > so you mean actually wrap a FileItem inside PartOnDisk and PartInMemory,
> > instead of creating our own FileItemPart subclassed from Part? Yes that would
> > work as well give or take a few bodges.
> >
> > Regards
> > Jorg

Mime
View raw message