Daniel Fagerstrom napisał(a):
Grzegorz Kossakowski skrev:
Yes, I agree with idea and would like to violate its independence and
that's why I seek for other solution.
After sleeping with a problem in mind I guess that situation is not
such dramatic and you can be probably right that passing only request
data is enough.
However, if pass for example uploaded files sent by browser we need to
think about:
1. Passing an XML stream serialized and encoded in request body, along
with data sent by browser
This is something we have discussed before isn't it? The main idea is to
extend the request and response object with some sax handling APIs.
Yes, we did. Here I'm talking about fall-back mechanism so called servlet does not have to deal with SAX. The idea was
to POST serialized SAX stream in request body. However, this solution is problematic if we have to merge that data with
the one sent by browser.
This fallback mechanism was to still stay compliant with standard HTTP technique and adding SAX handling just for a sake
of performance.
WDYT?
2. Avoiding reparsing again and again input data sent by browser
I really see both points quite troublesome. For first one, I guess we
would have to encoded that stream as yet another file the same way as
browser encodes multiple uploads.
Any thoughts, hints?
For the multi part mime parsing that is used for e.g. uploads, the main
problem is the way that this typically is handled in servlet based
webapps. I.e. that all multi part mimes are handled already in a filter
that is used before the servlet. In Cocoon it would be more natural to
do multi part mime handling in the sitemap so that different things can
be done for different URLs. Also the mime type handling could be
deferred to the actual servlet service that is going to use it instead
of doing it in front of the main servlet.
One could also consider havíng servlet service specific filter chains.
This could be implemented with Spring interceptors that are added to a
servlet service and intercepts the servlet calls.
I'm not sure if I follow you here. Do you want to say that parts parsing should work in lazy mode, so if caller of
service does not deal with parts double parsing is avoided, right?
Certainly, this functionality would be useful but I fear that it would
take me a lot of time to do it properly. Any chance that you will be
able to help in foresable future?
That is my intention.
Great. Thanks!
--
Grzegorz Kossakowski
