Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3BCAE988.9FB3D1E1@apache.org>
Date: Mon, 15 Oct 2001 15:50:00 +0200
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Flowmaps revisited
References: <20011012134634.36746.qmail@web20405.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Finn wrote:

[... skipped bunch of good questions ...]

> Differential Analysis
> =====================
> On the reusability of flows: the sitemap as it stands
> seems suited towards the publishing roots of Cocoon;

Yes, exactly and since there are very few publishing-only web sites
nowadays, this is the reason to move to a more general description.

> sites that manage documents where strict standards can
> be imposed and sitemap rules can be written to define
> relationships.  Most of the flowmap/transition map
> proposals I've seen seem suited towards simple
> applications or single-site portals.  I'd like to
> encourage us to consider scaling these ideas up to a
> model where multiple applications could be created
> from a library of reusable subflows (groups of states
> and transitions).  As it stands, the transition map
> design you propose gets us closer in that it
> formalizes a set of transitions, but it still seems
> like something that wouldn't scale up to a larger
> development staff working on multiple apps in parallel
> who seek reuse and commonality of subflows.

Believe me: I'm with you on this. In my previous comments, I started to
analyze the overall topological complexity in order to understand the
topological unit and the semantical unit that allows us to describe it.

Then, once we have done this and all feature concerns are met, we must
understand how to make it easier to use, reuse, develop and maintain the
information, judging the entire thing with a clear SoC-based metric.
 
> What I'd propose is a variation on what we use: we
> create a global dictionary of the transition
> information.  Like a sitemap, it can centralize (or
> partition) the definition of reusable states and
> transitions.  But unlike a sitemap, this dictionary
> provides an interface that hides the representation of
> the transition information; if at some point you want
> to store the state/transition info in an XML database,
> you could do so.  (For now, we use a separate XML file
> that hosts this info outside the sitemap.)  This
> dictionary allows you to load state/transition
> relationships by name.  We think this might help down
> the road when we create an IDE for dragging in
> pre-packaged subflows to define an application.

Carefull not to touch the dirty mud of dynamic transitions: it's the
same thing for dynamic pipelines in the sitemap and I'd consider it a
bad design decision at this point.
 
> Are there enough reasons to store this outside the
> sitemap?  Maybe not.  

No, from a semantical point of view

 statemap = sitemap (state descriptions) + flowmap (transition
descriptions)

thus, I believe we should aim at writing one semantics for both and
afterwords, understand how to make it possible to fragment it into
different subfiles based on SoC metrics.

> But as I see the sitemap grow
> and grow as we'd add this information, it becomes
> apparent to me that for maintenance purposes on a live
> site, you'd probably want to externalize this and
> allow more freedom of how updates are made and
> managed, without touching the sitemap (just like we
> don't like to touch cocoon.xconf unless there's a good
> reason).

Hmmm, no. I disagree: a FSM has a statemap that is fixed and should
rarely require changes (on production, that is). Making it possible to
load it into a database or another repository of that kind, suggests a
more dynamic approach that will soon become a pain in the ass to debug
and maintain.

I would strongly suggest against such a decision: statemaps, just like
sitemaps should be the equivalent of configuration files.
 
[...]

> Other General Comments
> ======================
> I very much agree with your point about delivering
> apps now.  I've tried to abstract as much of our
> architecture outside of Cocoon as possible to prevent
> a moving codebase from hurting us.  I'd love to get
> the right solution tunneled into the base
> architecture, but I can't wait, so building this
> initially as extensions appeals to me (especially if
> we can devise an upgrade path to future versions to
> preserve the pages and flows we're creating.)

Ok, we'll proceed incrementally, which is, also to me, very appealing.
 
> Finally
> =======
> Finally to Stefano and the rest, I'd like to say how
> impressive the Cocoon architecture is...RTs like this
> one prove that much of the value of the architecture
> comes from its ability to stimulate independent
> innovation around the globe.  I find this feature, and
> these discussions, as valuable as the actual code.  It
> was a pretty cool week to find Daniela's message in my
> inbox literally 12 minutes before a design meeting on
> the same topic, and then Ovidiu's SOAP work delivered
> less than 24 hours later.  Very impressive.

Thanks. Remember that you are part of this as well :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org