cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Less is More, Finite State Machines and Balkanization
Date Fri, 11 Jul 2003 19:52:50 GMT
Stefano Mazzocchi <> writes:

<snip on intro/>

> Marc is advocating that "there is more than just 
> continuation-based flow control" and he is dead right: there 
> are as many ways to implement flow control as there are stars 
> in the sky.
> But there are two major families of approaches: procedural 
> vs. declarative.
> The continuation-based flow is procedural. What Marc is 
> proposing in his wiki page is declerative. state oriented. in 
> short, it's a FSM. it's the "goto" equivalent for the web.

I'd respectfully disagree. The two models are (or should be) more like
procedural and functional.  Functional does not have to be state
oriented.  I'm not sure I can make the distinction clear, but again this
comes back to the issue I keep raising:  a rule based evaluation vs. a
procedural evaluation can both achieve exactly the same thing.  Rules
may appear to be declarative, but only in the sense that the statements
of a procedural language are declarative.  The difference is that
instead of doing dynamic evaluation of the data you are doing dynamic
evaluation of something that is more abstract (ugh); a mapping of data
to logic.

Consider for a moment creating a flow graph as an XML document.  Cycles
have to be handled via refid (or similar) but otherwise it's
straightforward not?  Once you have it you can combine it with any other
context information.  At that point running an Xpath over the combined
context to evaluate the next step is a functional evaluation of the next
step ( as opposed to a procedural if then else block evaluation of the
next step ).

> I'm sorry, but I cannot stop considering this harmful. or, at 
> least, a poor substitute (for this kind of usage) for what we 
> achieved with continuation-based produceral flow descriptions.

I'm not sure that allowing alternative approaches is a good thing at
this point.  However, I don't see how some abstraction hurts?  Having
said that, I ran across this on the xml-dev list this morning:

The quote that caught me eye "Extensibility makes abstraction
expensive." is perhaps particularly relevant to this question?  However,
the converse -- abstraction makes extensibility expensive" is not
necessarily always true...

<small snip/>

> Sylvain likes abstactions. Otherwise the sitemap interpreter 
> would be called SitemapInterpreter instead of TreeProcessor.
> I used to love abstractions as well.
> Now I'm far more concerned about them: less is more.

That's the good thing about abstractions: they have less semantic
baggage than a specific implementation.  Or to put it another way, one
good abstraction can replace a dozen more concrete specifications...
> Cocoon is powerful because there is *ONE* sitemap semantics 
> and my continuous obstructionism to the pluggability of 
> sitemap semantics forced discussions to happen, that created 
> community and focused development.
> The sitemap and the flow are the core of Cocoon. Abstracting 
> them will balkanize the cocoon community.

Huh? Pipeline, Generator, Map(!) and friends are highly abstract in the
Cocoon context! They happen to be good analogies to concrete real life
things, but they have nothing to do with the real life things.  Cocoon
works because it has good abstractions (that people can understand) not
because it doesn't have abstractions! I think you're on the wrong track
> I'm *strongly* +1 to anything that will force discussion and 
> improve the existing ideas (as we did with the sitemap 
> semantics over the years and as we did with the FOM recently).

Appreciated, I'm not trying to be dismissive or argumentative here.  As
I discussed with you when the flow sitemap integration discussions where
in full swing I do have a long term agenda (XSLT managed flow) and I
would like to see a way of including it in Cocoon without breaking
existing functionality...


> We choose one direction for our core and we keep evolving 
> that. No polymorphism just because a few people have legacy 
> they want to reuse, it's not our problem.

That makes sense. I'll note that abstraction and polymorphism are not
the same thing...   Confusing reuse of semantics is different than
generalized terminology.  One can lead to the other, but careful design
(interfaces, interfaces, interfaces) can also prevent it.

> Yeah, the next thing to unify will have to be the form 
> handling. XMLForm and JXForm will be shortly unified. 
> Hopefully, Woody will be as well.
> Balkanization is the problem. FS is the signal. Community 
> fragementation is the danger, expecially when blocks will be there.
> So, instead of routing around consensus, let's work toward it, that
> means: no abstraction for core parts.

I think we've already got lots of it, perhaps everyone is just so used
to working with it that mostly we see it as concrete...

View raw message