cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <p...@apache.org>
Subject Re: [Moving on] SAX vs. DOM part II
Date Tue, 25 Jan 2000 01:15:32 GMT
brian moseley wrote:
> 
> On Mon, 24 Jan 2000, Pierpaolo Fumagalli wrote:
> 
> > Ok... But in this way you're not talking about a Mail
> > Servlet. You're talking about an E-Mail to HTTP gateway.
> > It's a COMPLETELY different thing than integrating
> > Cocoon into a mail server... (again, take a look at the
> > James source code! java.apache.org)
> 
> dude. i am now convinced that you have not actually been
> reading my mail. i never once said i was talking about a
> mail servlet. in fact i twice explicitly said i was not!

AAARRRGGGHHH :) I'm killing him... :)

> im not talking about an email to http gateway either. i'm
> talking about subclasses of servlet request and servlet
> response that can be used by cocoon interchangably with http
> servlet requests and http servlet responses.

Ok. Got that. Let's do one thing. I think we can do what you want to do
with EMails (I got out all those papers on EMail research I made between
98 and 99). The thing is that we cannot rely on ServletRequest and
ServletResponse object (right now). They're too tied to the HTTP model.
If we can come up with an analogue set of classes that can embrace both
cases, I think we can think about plugging in Cocoon capabilities into a
mail server (read James, because it's already there)

> the sitemap is the only part of cocoon that depends on the
> request uri, right? of the framework, i mean, not of
> individual producers.

Almost correct... In Cocoon 2.0 all components are supposed to receive
instances of ServletRequest and ServletResponse. But we can design our
classes, that "fit" both worlds and do what you need to do.

> if that's the case, then cocoon should
> in general be able to operate on request and response
> interfaces rather than on http specific request and response
> classes. the parts of cocoon which are http specific should
> only be invoked when handling requests known to be made via
> http.

Right now it's tied to HTTP, but I finally see your point (must be the
fact of being born in a non english-speaking country, or the layer of
grease and rust that populate my brain).
Can we think about having a generic (not protocol-specific)
Request-Response (and Context) object expecially designed for XML
production? We need to draft those quite soon, because Cocoon 2.0 relies
100% on that (and I need to have a Beta for XTECH 2000, end of
February!)

	Pier

-- 
--------------------------------------------------------------------
-          P              I              E              R          -
stable structure erected over water to allow the docking of seacraft
<mailto:pier@betaversion.org>    <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------

Mime
View raw message