[RT] Better Environment Abstraction

[Nicola Ken Barozzi]

I have some problems I need to solve:

1) I want to use Cocoon as a bean in other programs, as an evolved xml processing bean. I want to create it, set input (stream), set output, and execute.

Problem: I cannot do it with the current Cocoon, without creating my specialized environment to put the input and a Generator that gets from that and generates.

2) I want to execute transformations of mails in a James mailet using Cocoon.

Problem: I have a similar problem to (1).
Cocoon doesn't get input directly from the request, unless from a webapp HttpServletRequest, which is not really feasable here.

3) The StreamGenerator depends on the servlet package, so Cocoon cannot compile without it. So much for blocks and reduced dependencies on core. Cocoon should be able to run in a smaller space, without depending on servlets.

Problem: As we use Cocoon in a container != to a servlet container (Avalon Phoenix, Mod-Cocoon) we loose the StreamGenerator functionality, or portaility of the sitemap, unnecessarily.


So I cannot get a stream from the Request in a standard way, though it's IMHO a reasonably common operation, that should thus be abstracted.

With Vadim we have discussed about it a bit and we found that:

1) not all env. have the need (CLI), but most do
2) some env.s (mail) have multiple inputs
3) IMHO all env.s have a main input (mail content)
4) it's possible to get these from the Request as attributes instead of as a stream. This makes it more flexible because I can pass objects, and more than one. Standard entries can be added.
5) getting stuff from a Request attribute means that I need to parse all the request. This increases memory usage, but sometimes is inevitable, because of the protocol used (mail attachments)
6) getting from a stream can make it easy to make it more efficient on input->output transformations, typical of web services.

So, from these, I seem to think that we could

1) add a getInputStream() to the Request
2) make other input features available through request attributes

In case of mail

1) the mail content goes through getInputStream()
2) the attachements go through Request attributes

There are other possibilities, this is what ATM seems more common ground and pragmatic.

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