cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: Experience with workflow at Hippo Webworks
Date Mon, 15 Mar 2004 20:31:51 GMT
Guido Casper <> writes:

<snip />

> > 
> >>Do you think you can encapsulate that behind an interface
> >>like this? -setState(doc, requestedState, user, optionalObject)
> >>-getState(doc)
> >>-getAllowedActions(doc, user)
> >>
> > 
> > 
> > I was trying to figure that out myself.  I guess the main 
> question I 
> > have is where are these interfaces going to be defined?  If 
> they are 
> > part of flow, then sure: have a function that calls a pipeline and 
> > returns a JS object with these methods attached to it.
> I was more thinking of Avalon components. That would mean if 
> you need a hook to call a pipeline generated JS object that 
> hook would need to be created (instead of using the one from 
> the flow layer - hope I'm making sense :-).

Ok, that's essentially my next suggestion.  I think having such
components would very quickly result in JS wrappers being built around
them for flow, so I think you're meeting everyone's needs.

> > 
> > However, I got the impression that not everyone wanted to depend on 
> > flow.  If this is some abstract object that gets tossed to some 
> > generic action handler that would also likely work, in particular, 
> > since once you have that you can wrap it for flow and make 
> both camps 
> > happy?
> > 


> > 
> > Well, given that XSLT is Turing complete I can't imagine 
> what would be 
> > missing?  Such an approach is definitely flexible: it allows for 
> > declarative state control if you want it, and it allows for 
> > declarative rules evaluation if you want that instead.  
> Given that it 
> > can also be used as the input to generate procedural code, you've 
> > basically got all three worlds?
> OK.
> TBH I don't know exactly what "Turing complete" means and I 
> don't think I can build such a thing with XSLT.

Basically, any Turing complete system is computationally equivalent to
any other Turing complete system.  Proving a system is Turing Complete
is, for most purposes, a way of saying that it can do any form of

However, just because a system is Turing complete doesn't mean that it
is easy to use...


> AFAICS JDO and XQuery _have_ been created bottom up (the same 
> is true for JDBC). Neither would be there without 20 years of 
> SQL (and other
> database) experience (and the way JDO was born was eagerly 
> debated - to say the least). I don't think JDO fits each and 
> every problem already being effectively solved with plain SQL 
> before (I want my workflow engine "talk SQL" :-).
I guess this depends on your definition of bottom up?  The way I was
understanding you was more along the lines as an incremental approach
starting very small.  Although JDBC has definitely been built
incrementally it was never very minimal?  Certainly, XQuery isn't
anything minimal or incrementally improved (yet)...  JDO, I guess lies
somewhere in between, but been a lot there since day one?

> > The usefulness of such a
> > thing for the general Cocoon community is just about nil; it's just 
> > too big and diverse of community.  (Having said that, I'm 
> the first to 
> > admit that our use cases fall on the far extreme edge of complex 
> > compared to what most people have to do.  I've never seen another 
> > project like this one in my 20+ years of IT and that 
> includes one that 
> > was over 500 Person years of effort.)
> > 
> > </long-winded-mode>
> > 
> > <expanded proposal>
> > 
> > I believe what we need is some way to accommodate everyone,
> Here I think we disagree.
> <skip-elaboration/>
> :-)

Ok, I'll bite; why? Do you think Cocoon shouldn't meet the needs of it's
entire user community?

> > so my
> > proposal is simply:
> > 
> > 1) a flow enabled engine that people can write flow script for 
> > directly. This needs a well defined set of interfaces, probably 
> > similar to what is being proposed for the work flow API;
> Yes, it might be just a first step and the basis for futher 
> evolution. But it might very well already be a solution for a 
> bunch of problems.

Yes, let's guess and say that fits 80% of the needs....

> > 
> > 2) *additionally* some way (Cocoon approved interface) to 
> persist and 
> > retrieve flow-script dynamically to feed it into the above flow 
> > engine.
> Yes, it certainly might be a nice workflow implementation to have.
Then maybe this would give us probably the remaining 20% for those who
need the whole thing?


View raw message