Please delete me from the mailing list...I'm receiving a bag of mail
-----Messaggio originale-----
Da: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Inviato: venerd́ 8 febbraio 2002 10.21
A: [EMAIL PROTECTED]
Oggetto: RE: Dispatcher/Adapter
> DZIEMBOWSKI,KINGA wrote:
>
> Hi,
> I feel that the tension of release is over, and we can return to the
> discussion on my proposal. I propose to add to the Cocoon project
> Dispatcher/Adapter concept. This set of interfaces and basic abstraction
> allows building pluggable extensions in a more standardized way. The real
> life example of such extension is our HP-SOAP Server. (You can download it
> from http://www.hpmiddleware.com/download.) But it is just one
> example, the
> imagination can bring much more.
>
> To refresh your memory the proposal, demo , patches and additions can be
> found at:
> http://soap.bluestone.com/proposal. The real HP-SOAP server in
> action can be
> accessed by:
> http://soap.bluestone.com/hpws.
> Please note the combination of Cocoon publishing techniques, XSP
> pages used
> as client forms to access SOAP services, with processing capabilities.
>
Hi Kinga,
yes we should now come back to this. As some of us here have already stated,
we are very happy about your donation and will accept it.
But, there is this *little* problem with HttpRequest vs Request problem.
If I remember it right, your solution requires some methods which are not
exposed
by the Request object (or Response object?).
I thought a little bit of this problem and I think this is a general problem
Cocoon has. So perhaps we can solve this on a higher level.
There are several custom libraries/projects which rely on the
HttpRequest/HttpResponse
interface exposed by the Java Servlet API. Cocoon decided not to use the
servlet
abstraction but an own one to easier integrate Cocoon into other
environments like CLI
or whatever.
To integrate all these custom libraries (like the HP donation, the PHP
generator
or the Deli component) there are currently two hacks used:
a) A custom component wraps the Cocoon Request/Response objects to provide
the full
Servlet API functionality
b) The HTTP environment puts not only the Cocoon Request/Response but also
the Servlet
variants into the objectModel, so they can directly used by custom
components.
Now, I would like to be able to use all these great custom projects inside
Cocoon
*without* the Servlet API even from CLI. So I think we need an *interface*
from Cocoon
to custom services using the Servlet API.
An easy solution would be to provide a HttpRequest/HttpResponse object in
the objectModel
by the environment as it is already the case today with the HTTP
environment.
Are there better solutions? Is this FS?
Regards,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
