cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: shared object Proposal
Date Wed, 12 Jan 2000 16:56:31 GMT
Brett McLaughlin wrote:
> 
> 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.

Great, I like your "evolutionary" vision a lot.
 
> >
> > > >
> > > > 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...

Mind you, I totally understand his point of view. In fact, he's the
first person in the world that tried Cocoon out, last year. His comments
were: sounds good, but I wouldn't use it, it's too advanced.

He's changed his mind a little, but not that much. In fact, I consider
ECS a total waste of programming effort, but I welcomed the project:
Apache is great because it covers almost all valid points of view. Then
you choose the best one.

Sometimes project converge (tomcat and jserv), sometimes die out (SPFC),
sometimes they remain where they are (JMeter) or struggle to break the
egg and come alive (James)... well, only the future will tell...

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

Well, your user application is forced to be a servlet and I don't this
totally breaks the fundamental "inversion of control principle".

So, no, I think the way to go is

web server -> servlet engine -> cocoon -> services

where something like your service engine is attached to Cocoon
(something like what Michael proposed).
 
> > 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?

No, but Avalon does _NOT_ define what we call the "working interfaces",
the methods that actually perform some work and are called by the other
blocks.
 
> > 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 .... ;-)

I see your point, but I still think Avalon is orthogonal to that. We
provide you code and interfaces like Configurable, Service, Component
and Composer. Much like Actor/Director today in Cocoon.

The working interfaces are Producer, processor, formatter, ... in your
example they would be "Executor", but you have to cast your Object to an
Executor in order to do something.

Service provides just init() and destroy() methods.
 
> > > 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 ;-)

Great, be my guest, here are my thoughts:

1) the "inversion of control principle" is a must, if you remove that
I'll be -1 now and forever so don't even try :) [read, the user code
will be called by Cocoon, not the other way around]

2) cocoon _is_ a framework and has a component model, today, that allows
services to be pluggable. Little impact on that already exists is of
maximal importance.

3) most Turbine services should be mapped with XSP taglibs (this is also
where the JSP.next proposal is going)

Here we are. Here's where I can reach. Your turn now ;-)

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