Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F0F3C30.9080108@apache.org>
Date: Fri, 11 Jul 2003 17:37:36 -0500
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Less is More, Finite State Machines and Balkanization
References: 
 <1E0CC447E59C974CA5C7160D2A2854EC097CDD@SJMEMXMB04.stjude.sjcrh.local>
In-Reply-To: 
 <1E0CC447E59C974CA5C7160D2A2854EC097CDD@SJMEMXMB04.stjude.sjcrh.local>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

on 7/11/03 2:52 PM Hunsberger, Peter wrote:

> Stefano Mazzocchi <stefano@apache.org> 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.  

Good point. I stand corrected.

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

I never said the opposite.

However, Fortran is a turing complete language. Would you like to write
your flow controller with it?

My point is: that fact that it is *possible* doesn't mean that it should
be done.

Marc's examples in his wiki page show clearly that the continuatio-based
flow implementation is the cleanest, less verbose and more explicit.

if you can provide me a real life example where a functional-based flow
controller can be cleaner than its flow equivalent, I'm willing to
change my mind, but I need examples, not accademic talks.

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

Sorry, I'm slow: I need examples.

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

Sorry for singing the same tune over and over, but your points are kinda
dry. You are basically stating that there is computational equivalence
between a procedural flow description and a functional one.

But this was *NEVER* even challenged.

The point is another: what can a functional flow description do *better*
than a procedural one? (better means: less verbose, more compact, more
readable, more maintainable, etc..)

so far, lots of accademic equivalences, but no real life evidence that,
for the web, a functional flow description is needed.

> 
>>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:
> 
>  http://www.eskimo.com/~jeremyk/archives/000078.html
> 
> The quote that caught me eye "Extensibility makes abstraction
> expensive." is perhaps particularly relevant to this question?  

I don't see how. I'm not proposing extensibility over abstraction. I'm
suggesting we don't do neither and keep the design evolution controlled
by the "less is more" paradigm, as we did so far.

> However,
> the converse -- abstraction makes extensibility expensive" is not
> necessarily always true...

abstraction at core service levels suggests polymorphism and
polymorphism of core services leads to community fragmentation.

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

I don't want a dozen more concrete specification. I just want ONE!

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

Well, for one, Map is *way* more abstract and everybody knows this is
hurting you (see the trend to generics).

As for Pipeline and the sitemap components, they were designed to be
abstract to allow polymorphism, but at the pipeline component level.

The different components (generators, transformers and serializers) were
*forced* to remain separate even if it was entirely possible to create
further abstractions and unify all of them.

And yes, Cocoon *abuses* interfaces and suffers from massive
over-componentization (injected by the avalon patterns, which I'm, at
first, responsible for)

There are cases where polymorphism *is* required. no doubt about that.

but a generator is *not* a core service, it's a pipeline component.

Imagine if we had sitemap engine easily pluggable: how many
implementations would we have? I'm sure several and that wouldn't have
forced the community to come up with a coherent proposal for the flow,
because simply everybody would have avoided reaching consensus and just
provide a new implementation of the abstraction.

I don't want to see this happening for the flow.

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

No, I think we are not talking about the same thing.

I define abstraction as "the logical common denominator between two
concepts". Therefore, if you have a FSM-based flow controller and a
continuation-based flow controller, you *abstract* your terminology to
come up with a common denominator that can fit both cases.

This is what Sylvain and Marc are proposing.

I like their abstraction, I just question the usefulness (from a
community dynamics standpoint) of such a change.

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

it seems like everybody has an agenda to place their favorite technology
right in the core of cocoon.

I'm against this. Cocoon doesn't need more than one core. It needs
focus, so that we can document it better, so that our users know what to
expect.

There have been no less than 4 different suggestions on how to implement
the flow controller before Ovidiu's was accepted as the one. (actually,
the vote is still pending)

I'm all in favor of evaluating new proposals and let them live
side-by-side in the scratchpad (like we had the sitemap interpreter and
the sitemap compiler side by side), and to merge the two if it makes
sense, but there should be one official one only.

I don't care what it is, it can be continuation-based or it can be based
on your granma favorites programming paradigm, I don't care.

But I want consensus and discussion, not polymorphism thru abstraction
to route around the community opinion.

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

Agreed. This is the case for pipeline components.

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

Yep, you touch a nerve: cocoon is heavily abusing abstractions and
people tend to see them as a "good thing"(tm) no matter what.

unfortunatley, this leads to several community problems and I'd rather
prevent a desease, than having to cure it later on.

[yes, the avalon problems made me really careful about how technology
impacts community dynamics.]

-- 
Stefano.