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?
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.
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?
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
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?
</snip/>
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
