Vadim Gritsenko wrote:
Nicola Ken Barozzi wrote:You lost me. What file request.getInputStream() should resolve to? Request is basically URL, and set of parameters (obtained from URL), there is no file in there.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.
Shit, this whole thing is getting me mixed up, right. So yes it's empty.
Request properties and/or attributes? And this will be work of environment to populate them.(2) new StringBufferInputStream(textMessage.getText())?Yes, and extra stuff in the attributes.
It would be, yes...
IMHO in the Generator it would be more easily pluggable and doable.Basically, it will mean that somebody will have to implement mail parsing somewhere, and then get desired content (XML for the File- or StreamGenerator). Why not do this work in request itself?(3) mimeMessage.getContentStream() or ((Multipart)mimeMessage.getContent()).getBodyPart(0).getContentStream()?
mimeMessage.getContentStream(), ie the raw mail.
Hmmm, I cannot really understand what advantage we may have in doing it the request... I'm actually a bit ignorant on this requst stuff, and don't understand it much, so it seems a hack to get round of using a direct stream and generators. I would like to make Cocoon simpler, and maybe this could be something of it? I really don't know unfortunately, I'll have to stay with your opinion here till I know better.
But we should get away with the StreamGenerator anyway, and make a source, no?
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.:)Hmmm, what if I have to make Cocoon work as a transformation engine?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.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?
Every request contains the data to go to the generator... do I have to buffer all the input in the request attributes?
Or a file system (current implementation). Can you start request processing before fully reading request? I guess not, because to start processing sitemap you need to have all request parameters parsed.
Geez, you're right again. Very good point.
To parse (POST-ed) parameters, you need to read body of the request, and if request is MIME, then request parameters could be in the last part of the MIME - thus, you will read up all attachements.
This sucks, but it's right.
hehehe You still have hope, it seems. ;-)Do you see a workaround for this?
Not giving request parameters if we get the stream directly , which could somewhat be an option in cases where the stream is the only thing that has the data. Do you think that in case of streams in some cases it could be done without request parameters? Probably could be something to investigate.
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 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).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.
See above - there is a need to read whole request before starting sitemap.
Yup, in the general case, yes.
Ok, you are correct again IMO. Many systems use streams to trnsmit stuff, but it's not necessarily like this in the general case.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.But pattern of the request is tied to the environment - thus,the only good place to split request on parts is environment. Sitemap and sources can be used to process these parts, but parts extraction should happen in the environment.
So yes, I again agree it should be in the environment.
So, stepping a bit back to solve the initial problem... how can we make this system be "generic" for all environments?
RT: Maybe if every "part" that the request creates is gotten in the sitemap as a source? Or as an inputmodule? For example, we can define standard entries in the Request to get the parts that the environment has gotten, like the inputstream one. Then we need to pipe it in the Generator, or directly, or as an internal link to that points to the resource in the request.
A bit convoluted this description, I hope you understand. Can you help me on this? I really want to remove that
dependency for the StreamStuffthe on the servlet.
--
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]
