cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Rowell <gr...@ctp.com>
Subject RE: shared object Proposal
Date Wed, 12 Jan 2000 14:28:48 GMT
> Stefano Mazzocchi wrote:
> 
> Brett McLaughlin wrote:
> > 
> > Stefano Mazzocchi wrote:
> > >
> > > Michael Engelhart wrote:
> > > >
> > > > on 1/11/00 8:05 AM, Brett McLaughlin at bmclaugh@algx.net wrote:
> > > >
> > > > > I'm +1 for the idea, -1 on your implementation 
> (nothing personal ;-) ).
> > > > > I think things like this do not belong (coded) in 
> Cocoon.  They are part
> > > > > of a large application frameworks, like Turbine 
> (incidentally, where we
> > > > > have implemented something similar to what you 
> outlined).  Those
> > > > > frameworks, which are designed to use things like 
> Cocoon (Cocoon, keep
> > > > > in mind, is a _publishing_ framework, not an 
> application framework),
> > > > > should handle services.
> > > > >
> > > > > So maybe take a look at Turbine, this is there, and 
> then Turbine can
> > > > > certainly use Cocoon for screen processing.
> > > > >
> > > > > -Brett
> > > > nothing taken personally ;-)  Thanks for looking at the 
> proposal.
> > > >
> > > > In some ways I agree but don't you think that Turbine 
> could be considered
> > > > overkill for smaller web applications?  Things like 
> database access (and
> > > > thus connection pools shared objects) are very common 
> if not a requirement
> > > > on even the smallest intranet that may not have the 
> need for something like
> > > > Turbine.
> > >
> > > Both are good points.
> > >
> > > Also, turbine should be included into something bigger 
> than that, the
> > > Avalon framework which includes all the required design 
> patterns. Cocoon
> > > should itself be an Avalon block.
> > 
> > OK, in theory I can go with this, but in practice, as you 
> pointed out,
> > this seems to be a ways off :-(
> 
> No, just way too early in time. Cocoon was believed 6/8 
> months ahead of
> time when I started it out. I believe Avalon is 2 years ahead of time.
> :(
>  
> > >
> > > But the problem remains: designing such a complex 
> architecture from
> > > scratch is _very_ difficult and error prone. Cocoon uses 
> some of those
> > > patterns and tried to come up with a working solutions.
> > >
> > > I know turbine people are lacking the publishing features 
> of Cocoon
> > > while Cocoon people are lacking the services Turbine does.
> > 
> > More than the actual services, I am more concerned that 
> Cocoon does not
> > have a services _architecture_ which Turbine does.
> 
> Good point. I agree.
>  
> > >
> > > Turbine people believe Cocoon is a piece of their 
> framework, but this is
> > > totally wrong. There is no such distintion as "application vs.
> > > publishing" framework. Because they mostly overlap in 
> dynamic content
> > > generation.
> > 
> > Really?  Which Turbine people are those ;-)  
> 
> Jon
> 
> > Since I'm the only one
> > floating around it seems, I don't agree with that... I do 
> think Cocoon
> > is separate from Turbine, just as say FreeMarker or 
> WebMacro are... but
> > I do think it will generally be a matter of Turbine calling Cocoon
> > (using Cocoon) and not the other way around.
> 
> No, well... yes, in some sense.
> 
> Here's what I mean:
> 
> 1) first case: Turbine calls Cocoon
> 
> web server -> servlet engine -> turbine -> cocoon
> 
> this is currently possible and allows turbine to generate pages using
> Cocoon as an API.
> 
> 2) second case: Cocoon calls Turbine
> 
> web server -> servlet engine -> cocoon -> turbine
> 
> this is possible but not implemented. This allows in practive so use
> Cocoon sitemap and turbine services. Most turbine people don't agree.
> 
> 3) third case:
> 
> web server -> servlet engine -> something -+--> cocoon
>                                            |       |
>                                            +--> turbine
> 
> 4) forth case:
> 
> web server -> servlet engine -> cocoon/turbine
> 
> but I don't have the energy to fight this battle.
> 
> > > So, what I want to see is NOT Cocoon called by Turbine, 
> or turbine code
> > > called by Cocoon, but a _well_designed_ framework that 
> includes both.
> > 
> > Hmmmm... what you are proposing is what I originally 
> proposed Turbine
> > would be.  I got ... ramrodded ... because Jon was set on it being a
> > Dash derivitive, and most people wanted working code.  So I 
> sacraficed a
> > lot of design to get a viable project started.  
> 
> And i agreed with that.
> 
> > However, I agree with you here Stefano, in theory. But is Avalon 
> > what you are certainly
> > referring to) close enough to useful to be that answer?  If 
> not, I have
> > to say Turbine is fairly close to that structure.  I am 
> close to adding
> > significant services architecture allowing things like XML-RPC for
> > remote services (without any user intervention), etc.  
> These belong to
> > the framework, not to an application.... if you honestly 
> think Avalon is
> > closer, I can switch gears and incorporate it there.
> 
> No, avalon doesn't deal with those things, it's a step below.
>  
> > >
> > > What Micheal proposed looks a lot like a light-avalon. 
> This is the road
> > > to follow, IMO, but, unfortunately, I don't have that much time to
> > > investigate what is needed to make Cocoon + Turbine unite.
> > 
> > Again, I'm not sure I understand what you consider "unite". 
>  Obviously
> > with the changes in CVS now, Turbine 
> screens/control/whatever can use
> > Cocoon for generation. Of course there is not the 
> integration so tight
> > that things like sitemap might sometimes apply targets to 
> Turbine, etc.
> > Is that more what you are saying?  
> 
> Yessir.
> 
> > If so, then we are looking at a wider
> > design (which I am for) but one that is not close to being realized
> > (which I am not so much for).  Worst case, we _have_ to 
> have Cocoon 2
> > and Turbine 1 (final) cooperating.  One way or another, 
> this is a must
> > in my mind.  Otherwise the ideas will lose interest....
> 
> Totally, but I'm not sure how this goes.
>  
> > I like the idea of a generic ServiceBroker, if you will.  
> This broker
> > has the responsibility of delegating requests for a given 
> Service.  In
> > this general scenario, not only would things like 
> Connection Pooling and
> > JNDI Contexts be services, but actual engines themselves.  
> For example,
> > I could request use of the Cocoon services, the Turbine 
> services (with
> > Turbine retooled), etc.  So in essence an application would have to
> > write their own custom control structure, but for all the 
> blocks, issue
> > requests to the service broker.  In my mind, these services 
> are _never_
> > cast to what they are and have specific methods.  Instead, you have
> > something like:
> > 
> > public interface Service {
> > 
> >   public String getName();
> > 
> >   public void setName();
> > 
> >   public void init(Object ob);
> > 
> >   public Object get();
> > 
> >   public boolean execute() throws AppException;
> > 
> >   public void destroy(Object ob);
> > 
> > }
> >
> > These general interfaces allow you tremendous flexibility!  
> You could
> > use the Service Manager to get a connection, for example:
> > 
> > Service connectionService = ServiceManager.getService("connection");
> > connectionService.init(jdbcURL);
> > Connection con = connectionService.get();
> > // Use the connecction
> > connectionService.destroy(con);
> > 
> > This is very clean.  It allows the service "provider" to do 
> things as
> > simple as returning a plain connection, or as complex as 
> very advanced
> > connection pooling, all without the user of the framework having to
> > worry about it.
> > 
> > In the same fashion, remote services become easy.  Based on 
> a property,
> > a request to getService() on a service that should be 
> executed remotely
> > would actually return an instance of XMLRPCService, unknown to the
> > user.  The servce manager would load up the service instance with
> > information about the service and parameters to call (set 
> in properties
> > files, for example).  Then when the user calls execute(), the
> > XMLRPCService would proxy the reequest across the network 
> to the service
> > remotely.  Of course this is transparant because of the clean,
> > non-casted Service interface.
> 
> Hmmmm, I see, yours is a special non-casted version of a light Avalon.
> 
> > In the same way:
> > 
> > Service cocoonService = ServiceManager.getService("cocoon");
> > cocoonService.init(myServletRequest);
> > cocoonService.execute();
> > 
> > And suddenly, you have output.  This isn't what the final 
> workings would
> > be, I think maybe instead you could actually init() the 
> Cocoon service
> > with a sitemap fragment or something, but it's the idea 
> that I'm driving
> > at....
> > 
> > So you wanna tear me up Stefano, or do you like this ;-)
> 
> Currently Cocoon is going in this direction:
> 
>  request --> cocoon -> sitemap -> cocoon-engine
> 
> while turbine is going in this direction:
> 
>  request -> turbine -> ??? -> cocoon-engine
> 
> they do not overlap, yet, but they are starting to do so.
> 
> This will make integration a pain in the ass.
> 
> I'll come up with something soon...
> 
Couldn't the sitemap mechanism itself be considered a service?

----------------------------------------------------------------------
Geoffrey B. Rowell
Cambridge Technology Partners, Inc.
8 Cambridge Center
Cambridge, MA 02142 USA
Tel: (617)374-9800
Fax: (617)914-8300

Mime
View raw message