cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 20:11:43 GMT
Stefano Mazzocchi <stefano@apache.org> writes:
> 
> 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?

Actually, the modern OO version of Fortran would be just fine ;-)  

> My point is: that fact that it is *possible* doesn't mean 
> that it should be done.
 
And the point of others is that nor does it mean that it shouldn't be
done.  Several people on the list have indicated they are working on
non-JavaScript versions of Flow.  Presumably they aren't doing this just
to be stubborn of because they are stupid.  The fact is that flow is a
_big_ problem, it is unlikely that it can be mapped by a single solution
space.  A scripting approach is fine for versions of flow where the flow
space is of small to medium complexity.  When the space gets to be huge
(we will have thousands of URL's, likely 10's of thousands) there are
scalability problems in a scripting approach that I can't see solving. 

> 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.
 
The actual controller is pretty darn ugly (we've got a pre-alpha, very
incomplete version so far), however, there's a big difference between a
rules based approach and a script based approach: the control of the
flow isn't managed by writing script any more, it's managed by writing
rules.  You decouple the management of the URI space from the
controller.  

In another couple of weeks we should be in production and I may have
time to start writing up a concrete example for you, but unfortunately I
can't take what we have at the moment and dump it here.  The only coded
example (tracking of medical lab data results) requires a huge amount of
auxiliary code that would take a week to turn into something that others
could related to.  

There is also currently a side issue in that my prevent any of this from
getting back to the Cocoon community; St. Jude is exploring what
portions of the application can be patented.  Currently, there's one
patent submission under way (it doesn't cover this portion of the code).
However, the point is, even if we where not able to contribute to
Cocoon, the use case we have is something that demonstrates other ways
of doing flow and demonstrates that there are legitimate reasons for not
assuming only a single way of managing flow within Cocoon.

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

I'll try and get you some.  In the mean time, let me put it another way;
think of an XML file that causes certain XSLT templates to get fired.
In our case the XML invokes the rules.  We match URI's against XML
patterns which then cause certain rules to get fired.  We don't invoke
the logic directly, there's an indirect relationship...  In  a way Xpath
and XML becomes your flow language.

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

Better is a relative thing.  For us it's better because we can write an
editor to produce the XML files that get turned into flow mappings.  We
have a more complicated flow engine than many people will ever want, but
it lets us turn the problem of mapping flow over to Business Analysts
and not require developers to be involved.  For us, that's a good thing.
Until I can take our domain specific logic and make it more generic the
work we've done wouldn't make sense for simpler flows, it would be a
huge amount of extra complexity. 

However, ultimately, my reason for wanting to turn this back over to the
Cocoon community would be because the rule engine would become
completely generic.  At that point, the average Cocoon user wouldn't
care about its complexity any more than they would care about the inner
workings of any other Cocoon component.

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

It's not academic.  However, I can't currently turn it into something
that's easily shared on the list.

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

I was wondering if it was the other way around; opposing abstraction so
as to ensure extensibility is possible?  It's an interesting (as in the
Chinese cure version of interesting) question and in other messages on
the list you've indicated that you're not sure how to find the balance
between making sure Cocoon is extensible and yet not out of control.  I
think as long as the discussions keep happening you're at least partly
making sure that happens. But I don't know the answer...

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

Exactly!  By using too concrete of terms you are going to ensure that
you have multiple specifications.  Some people don't want to use a
specific term like "Script" because it implies a particular
implementation.  So use sitemap semantics that aren't too concrete, keep
them somewhat generic.  Include only a single implementation within
Cocoon for now, but don't preclude other lines of attack on the problem
by using too closed of terminology. 

> >>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.
 
So why is flow any different?  Yes at the moment JavaScript flow is very
compelling.  However, that doesn't mean flow can't be a 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.
 
It seems like there is already a good amount of momentum behind the
JavaScript version of flow that is going to keep it alive no matter
what.  It also seems that its particular capabilities won't be affected
by keeping the sitemap semantics generalized.  

> > 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.
 
Well, again, I can't see a real danger.  Flow has good support, Sylvain
and Marc may or may not garner a following for any version of flow they
implement.  I'd suspect the probability of our work (XSLT flow) of
gaining a large following is even smaller.  From what I can see the
community dynamic won't really change; JavaScript flow will have a good
strong community simply because it is very powerful and very well
supported.  The side experiments may or may not go anywhere, but at
least they will happen and if nothing else provide validation that the
JavaScript implementation is the way to proceed.  Alternatively, they
may spin out new ideas for the JavaScript version. Just possibly they
may build a community of their own.  That would be nice for our code,
but currently I'd just like to have a way to hook it into Cocoon without
having to modify the guts of Cocoon.

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

I don't think I said the XSLT flow should be part of the core.  What
we'd like is a way to hook it into Cocoon without having to modify
Cocoon.  It would be nice if the hooks to do so used generic enough
terminology that our developers didn't do a double take every time they
looked at the Cocoon sitemap.

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

I simply think flow is too big of problem to solve with a single
implementation.  Taken to absurdity that seems like saying there should
only be one Generator in Cocoon, period...  

> 
> > <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.
 
Great, give me my generalized semantics and well defined flow interfaces
and I'll be happy... :-)

> >>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.
 
Open Source communities are always going to be volatile things.  It's
not abstractions that cause the problem, it's the shared interpretations
or misinterpretations of the abstractions that cause the problems.
Conversely it's also the lack of abstractions that force people to go
contrary to an accepted practice that cause problems.  Soooo, you need a
balance, good abstractions with good documentation and good interfaces
with well designed, best practices sample implementations that every one
can easily focus on.  That leave room for experimentation and growth
while helping to ensure that most needs are met through a single version
of the code.

> [yes, the avalon problems made me really careful about how 
> technology impacts community dynamics.]
 
I think the problem we discuss here grows exponentially when trying to
design a common infrastructure component such as Avalon...



Mime
View raw message