Grzegorz Kossakowski skrev:
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?
I agree.
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?
That would also be a possibility. I rather meant that instead of
indiscriminately parsing all multi part mimes in a filter, the actual
parsing should be done first in the servlet service that actually is
intending to use the parts.
/Daniel
