cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <bmcla...@algx.net>
Subject Re: shared object Proposal
Date Wed, 12 Jan 2000 15:18:25 GMT
Stefano Mazzocchi wrote:
> 
<snip />
> >
> > 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.
> :(

I don't mean ahead of our time in the collective sense, I mean in
practice as in the code being implemented.  This is moot, though, and
not worth arguing over...

> 
> > >
> > > 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.

So what I think might be a better idea is to begin to look at a services
architecture, either as a break out of Turbine, and maybe putting into
Avalon, or as something much less tightly coupled to Turbine.  I think
the service architecture should then be inherent to all Java Apache
projects.  This begins to fit into the postings you are making regarding
"I break the first egg."  I don't like having to create new methods os
using service for every project; however I agree that Turbine is not for
everyone.  In fact (shhh....) I use my own "flavor" of it that is
radically different than the public version for my work projects.

> 
> > >
> > > 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

heh heh...

> 
> > 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.

But I _hate_ this...

> 
> 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.

I _hate_ this too.

In either (1) or (2) you force a controlling structure on the user
(either Turbine or Cocoon).  I want the main control "Servlet" or
program or whatever to be whatever they want.  I don't think all
applications should be forced to either use org.apache.turbine.Turbine
or org.apache.cocoon.Cocoon as their control structure.

> 
> 3) third case:
> 
> web server -> servlet engine -> something -+--> cocoon
>                                            |       |
>                                            +--> turbine

This is getting better.  I propose:

web server -> servlet engine -> (user's application) -> service
architecture
                                                             |
                                                             +--> Cocoon
                                                             |
                                                             +-->
Turbine
                                                             |
                                                             +--> Any
Java Apache Project
                                                             | 
                                                             +-->
Traditional service (connection pooling, JNDI, etc)

> 
> 4) forth case:
> 
> web server -> servlet engine -> cocoon/turbine

I don't care about this one.  I won't spend time on it. I think (3) is
the answer.

> 
> 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.

I don't think that the interfaces are a step above.  I think the
implementations may be, but I think defining the archtiecture through
interfaces is well within Avalon's scope.  Do you disagree with that?

<snip lots of stuff />

> 
> > 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.

I really don't want the users to cast much.  The problem with that is
you give the user too much information about the services/objects they
are given by a broker.  It cuts down on the ability to transparently
perform operations such as XML-RPC, such as not having the user have to
know if they are using XML, LDAP, RDBMS, etc., as a data store,
performing advanced resource pooling, instance management, etc.  If you
have an object that is generic enough to not need an explicit cast, all
these things can happen without the user knowing.  I see this as very
important, as it allows transparant changes to pieces of architecture
without requireing code recomplilation.  Loose couplings.  loose
couplings... chant it .... ;-)

> 
> > 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.

Yup.

> 
> This will make integration a pain in the ass.
> 
> I'll come up with something soon...

That's, honestly, not what I really want.  As happy as I am with your
ideas, I want the rest of us (let's be honest, I want me) to start
coming up with driving ideas.  I think everyone in Java Apache, and I
might say particularly in Cocoon land, relies on the genius of a few. 
This is terribly unfortunate; although the ideas that come out are
great, and everyone certainly makes suggestions, the implementations
sometimes are done by that same few, if not a single person, creating a
hugh road block in progress and clarity of code.  I have an entirely
different perspective than you because I use this stuff in a company who
cannot accept 99.999% uptime, who cannot accept "it's coming in the next
release," or "It's aleady ahead of it's time."  That's not any better or
worse than your more "visionary" view, just a different one.  

So give me your input, as I intend to come up with something here.  I
think Avalon is nice, but I think it is missing a layer, or at least
another project/whatever, to handle the integration of all these
components in a better way... I really think you need to keep working on
this component (Cocoon) but we have to at the same time get working on
the integration you refer to.  So you give me your thoughts, and _I'll_
come up with something soon ;-)

-Brett

> 
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------

Mime
View raw message