Vadim Gritsenko wrote:
Nicola Ken Barozzi wrote:

[...]

Yes, I understood, I replied with the possibility of a source that builds on the Request inputstream.


Ok, what would be the InputStream for:
(1) CommandLineEnvironment
(2) JMSEnvironment
(3) SMTPEnvironment

[thinking process goes here]

Possibilities:
(1) Empty?
The CLI environment can resolve the file and give that in the request, as the servlet does.

(2) new StringBufferInputStream(textMessage.getText())?
Yes, and extra stuff in the attributes.

(3) mimeMessage.getContentStream() or ((Multipart)mimeMessage.getContent()).getBodyPart(0).getContentStream()?
mimeMessage.getContentStream(), ie the raw mail.

Point is - before adding getInputStream() there is a need to understand what does it mean outside of servlet env.
Yes, now I understand what you mean.

Same place where MIME is decrypted and file attachments are processed.
I don't understand what you want to do with the request factory here
If the Request interface doesn't have inputstream, it simply doesn't, what would you like to do with the factory?
Request i/face does not have inputstream right now, but it is still possible to process it - save files or read mime - thanks to request factories. Same here, if the only point is to read XML out of request input stream, this can be done in request factory and this XML could be saved as DOM object, as a request attribute(s) - same as FilePart is stored in the request now.
Hmmm, what if I have to make Cocoon work as a transformation engine?
Every request contains the data to go to the generator... do I have to buffer all the input in the request attributes?

For SMTPEnvironment, this can be several DOM objects - one per each MimePart containing XML, also you can save attachements the way it's done for servlet environment, and have plain text as request attributes too.
But I want direct feed to the pipeline. This about using Cocoon as an xml transformation engine, for example to adapt xml streams for business xml processes. I ant to send the data to be processed to Cocoon, not have to call Cocoon so that it calls me in turn and processes my stuff =-)

[...]

I want to add a getInputStream() method to the Request interface. And make a cocoon source to get it in the sitemap.
If input stream works for all evironments, then it's the way to go. But I'm just not convinced yet.
I understand what you mean. But I'm unconvinced of the opposite... anyway, we can have both inputstream and request factory stuff. The latter can also use the inputstream to be able to create attributes in a lenient mode (ie only if requested).

Also, the info to get the steam is conceptually in the environment, not in the request factory that is used nevertheless by them. One thing is getting the stream (inputstream), another is understanding the pattern of the request.

Let's continue this, please :-)

--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to