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: Experience with workflow at Hippo Webworks
Date Mon, 15 Mar 2004 22:31:01 GMT
Guido Casper <gcasper@s-und-n.de> writes:
> 
> Hunsberger, Peter wrote:

<snip/>

> >  
> > 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?
> 
> I refer to bottom up primarily as a way to tackle a problem. JDO and 
> XQuery certainly build on the experiences made with SQL (and would be 
> doomed without it).
> 
> Workflow (AFAICS) means many different things to many people. 
> I think we 
> must start small to really find out what kind of problems 
> people want to 
> solve with workflow (that's much harder by just discussing). 
> If people 
> have somthing to play with it might encourage further ideas 
> (driven by 
> their needs) and the whole thing (hopefully) starts evolving. 
> Otherwise 
> we might end up with the perfect solution to a problem that 
> most people 
> don't care about.

Hmm, not sure.  Work flow has been around well over 10 years and pretty
well defined for all that time.  It's missing a single language such as
"SQL" but the various XML standards seem to have many basic concepts in
common.  You need a certain minimum set of functionality to have work
flow in any real sense of the concept.  

Having said that, yes start small, build a basic API, but like I said
previously, having done so, be prepared to throw it out (or at least go
though a Woody to cforms like conversion)...

<snip/>
> 
> >>>
> >>><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?
> 
> No, I think there is no way to accommodate everyone. The 
> harder you try 
> the more you might move away from that goal.
> 
> Let me refer to the 80/20 point again and to this blog post (doing a 
> better job explaining than myself): 
> http://www.magpiebrain.com/archives/000198.html

We're building a framework here.  By definition it's got to do a lot
more than 80%.  XML without namespaces anyone?  How about not being able
to plug in Saxon?  

Sure, sitemap and flow don't make everyone completely happy, but I don't
think anyone will argue that they do far more than 80%?  In my book they
are pretty close to 99%.  I don't think I'd expect anything less from
the Cocoon project for work flow either.... :-)  

Now, I'm not saying that you have to implement 99% of the work flow use
cases any more than I expect Cocoon to come preloaded with 80% (or even
20%) of all the possible HTML forms in the world.  What I am saying is
that whatever is provided has to be flexible enough that the Cocoon
community can implement 99% of their use cases themselves.

<snip/>


Mime
View raw message