Return-Path: 
 <cocoon-dev-return-37789-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 39243 invoked by uid 500); 5 Mar 2003 16:48:15 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 39188 invoked from network); 5 Mar 2003 16:48:14 -0000
Received: from gate2.stjude.org (192.55.208.12)
  by daedalus.apache.org with SMTP; 5 Mar 2003 16:48:14 -0000
Received: by gate2.stjude.org; (8.9.3/1.3/10May95) id KAA1408900;
 Wed, 5 Mar 2003 10:48:15 -0600 (CST)
Received: from somewhere by smtpxd
Message-ID: <601F6322AD71D5118D6C0003472515290660D183@sjmemexc1.stjude.org>
From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: [RANT] The Flow...
Date: Wed, 5 Mar 2003 10:48:12 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Pier Fumagalli <pier@betaversion.org> wrote:

> <Peter.Hunsberger@stjude.org> wrote:
> 
> > Pier Fumagalli <pier@betaversion.org> wrote:
> > 
> >> <Peter.Hunsberger@stjude.org> wrote:
> >> 
	<snip>
> > 
> > Fair enough, but how about a high level sketch of where the other 
> > parts fit in?  Something like:
> > 
> >        complete model
> >             |
> >      +------+----------+
> >      |      |          |
> >    flow  environment  whatever
> > 
> > Where only "flow" is completely documented at the moment? 
> (And yes, I 
> > realize the hierarchy is probably more complicated than 
> that, that's 
> > why I need some documentation...)
> > 
> > I fear that if you only document "flow" people will add 
> things to flow 
> > because they don't know where else to put them...
> 
> Most of the rest of the stuff is accessible from the JavaDOC. 
> It's fairly easy to see what does what from that kind of 
> documentation. Ok, it might be better to have a nice paper on 
> where the different bits come into play (what's an 
> environment, when it's created, how does the sitemap 
> processes requests and how its components deal with it, and 
> so on)... Volunteering yourself? :-)

Well, if I understood things well enough to document them I probably
wouldn't be asking for them.  However, I'll eventually end up doing some of
this, but it's going to take a year or so...

> 
> The flow requires a different "API" documentation, much like 
> the W3C dom specification and IDL definitions, because it has 
> to deal with several languages, it's partly defined in Java 
> and partly in the language of your choice (JavaScript for 
> now, Python and others as well in the future?), and it deals 
> with an object model "instantiated" in several points of our 
> codebase...
> 
Again fair enough, except yesterday I also asked why any of the "layers" (so
to speak) can't have "controllers" written in any language you want (IE; BSF
interfaces back to a meta-controller).  Flow is the current problem domain,
but if you step back and look at the really big picture, you'll eventually
want to do the same thing for work flow as "flow" is doing for presentation
flow.  Then, once you've done that you'll want to manage the rest of your
business logic in the same way as you manage work flow.  If you've got such
a capability, it would be good to allow people to plug in the language of
their choice for the controllers (interesting problem when concepts such as
continuations are missing from the language), and at that point you've got
to have a complete abstract object model compatible with any language... 

Yes, I know I'm jumping ahead of the game, but I keep wanting a complete Web
app Object model that makes sense and it seems that Cocoon is as close to
anything to getting there.  If there was a good abstract model to shoot at
it would be easier to make sure that Cocoon actually did eventually get
there...