cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From brian moseley>
Subject Re: servlet or no? (was Re: [Moving on] SAX vs. DOM part II)
Date Tue, 25 Jan 2000 00:22:15 GMT
On Mon, 24 Jan 2000, Pierpaolo Fumagalli wrote:

> brian moseley wrote:
> > 
> > On Mon, 24 Jan 2000, Pierpaolo Fumagalli wrote:
> > 
> > > Are we talking about CACHING the XSP (the class file
> > > produced...) or we're talking about executing XSP
> > > gathering request (and response) informations from an
> > > E-Mail?
> > 
> > i don't think of it as caching. in my deployment scenario
> > the application never adds or removes compiled classes. it
> > only loads them, and reloads them when it notices they have
> > changed on disk.
> > 
> > from the point of view of the offline compiler, you might
> > consider it a cache.
> > 
> > either way, we are certainly not talking about executing the
> > logic in response to an http request, or any other kind of
> > request.
> So, when do you execute the logic? I'm starting to loose focus.

step 1: scheduled process extracts raw logicsheets, etc from
say a cvs repository, compiles them into classes, and
distributes the classes to the appropriate location on the
host running a cocoon server.

step 2: the cocoon server handles a request and decides it
needs one of these classes as a processor. it notices that
the class's last modified time is newer than the last
modified time that it remembers for the class. it reloads
the class and then executes the code appropriately.

step 1 is performed offline, from the perspective of the
cocoon server. the classes are not cached, from the
perspective of the cocoon server. the relationship is much
simpler, just 'reload if modified since x'.

this is a perfectly valid deployment, and is in fact much
more highly scalable (performance-wise) than
load-at-request-time strategies. at least in my experience.

> But the SMTP and HTTP models ARE orthogonal.. How can
> you reconcile those? SMTP doesnt' provide a
> request-response mechanism, while HTTP does.


i am not talking about smtp. i have never been talking about
smtp. please understand this.

> > i didn't say they are. smtp and http are equivalent
> > transport mechanisms for mime data.
> But their operation model IS different.

fine, who cares? im not talking about using cocoon as an
smtp handler.

> I like this guy... He reminds me of another guy I knew
> around october 1998 when he, with a friend, invented a
> thing called Mail Servlet... :)

augh. its like im beating myself in the head with a hammer.

View raw message