cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M Heuer" <>
Subject Re: [Moving on] SAX vs. DOM part II
Date Mon, 24 Jan 2000 12:33:15 GMT
> > Uh.. Totally... I wanted to say that many of the components used in
> > Cocoon, can be reused also in another tool dealing with XML translation
> > triggered by EMail events...
>Maybe I forgot to distill the essence of my concerns...
>If Cocoon is a pure Engine (my main proposal), not a servlet per se, then 
>Requestors and Responsors are "outside" the Cocoon core.
>Ok, drop in the Servlet Request/Response pair as a standard wrapper, but it
>will allow me to do my dedicated Custom stuff a lot easier. Now, the reason 
>the issue is raised, is that laziness seems to proliferate in OpenSource
>projects, and if the Servlet model is "hard-assumed" and the whole servlet
>context is passed and must be present, it will limit all other uses, 
>command-line (off-line) generation, or Emails in my case (Alarm events
>(application) trigger the generation of a bunch of status pages to be sent 
>And having Cocoon as a pure engine, it will make it more appealing to drop 
>into larger application frameworks as a standard component. That is a point 
>consider for wider acceptance.

I tend to dream along the same lines.  If I could issue a generic request, 
ie. one not tied to the servlet paradigm, I could use the cocoon publishing 
framework in a wider range of applications.

However, cocoon is primarily a _web_ publishing framework.  The changes 
required to generalize the request/response implementation might hurt 
cocoon's ability to serve web pages.

It's a tough trade-off...

Get Your Private, Free Email at

View raw message