cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M Heuer" <heue...@hotmail.com>
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 
>all
>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 
>why
>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, 
>including
>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 
>by
>email).
>
>And having Cocoon as a pure engine, it will make it more appealing to drop 
>it
>into larger application frameworks as a standard component. That is a point 
>to
>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...

   michael
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Mime
View raw message