On 16 Feb 2006, at 22:40, Sanjiva Weerawarana wrote:
+1 for importing the codebase into 2 subdirectories to start with.
However, if we want to merge the two into one, then let's make it a
goal
that we don't release anything until we've figured out how to cut-n-
chop
& mix-n-match to make that real.
I don't really understand what this means. Today both codebases have
significant numbers of users. We've been using PXE on ServiceMix for
about 6 months now - one of the things I'm looking forward to is
getting the latest PXE code to work with ServiceMix as its a bit
broken currently :). We're also keen to reuse the Sybase code in
ServiceMix - right now.
Integrating the two code bases together is gonna be a slow, iterative
process; we're talking complex code here. It could be that to start
with things are completely separate, after 6 months they are 10%
common, 2 years 50% common etc. The figuring out "how to cut-n-shop &
mix-n-match" could well take 5 years as this is an ongoing iterative
process. Sure we'll be heading closer and closer towards a unified
engine but it could take a long time to get there (and pieces could
very well never completely merge).
So are you saying that neither code bases will be able to even do a
milestone release for other people to use them until the community
has everything completely figured out years from now?
I don't quite follow this restriction - why not let the project
release milestones when it feels it has something useful for its
(already existing) user base?
I too greatly prefer the idea of having one BPEL engine (properly
layered ofcourse .. the part that does the core language vs. the part
that does people-facing activities etc.) as there's little benefit in
having multiple of those in ASF given it'll simply reduce the
available
developer resources.
While its a worthy goal that I share, I'd advise against forcing this
outcome from the start. Look at something so trivial as parsing XML
into some data structure; we have 4 different projects I can think of
at Apache (there could be more); XMLBeans, JaxME, Axis, Xerces -
which all do it in very different ways. Orchestration is way more
complex than XML parsing (have you seen how big the PXE codebase
is? :) and its fine if we have different implementations of things
within Ode as there are various ways to do it (e.g. persistence can
be done many different ways - you can orchestrate via pi-calculus or
state machine etc).
Its a worthy goal to reuse as much code as is possible - most
developers I work with in open source do this anyway without being
told to do so. I'm quite concerned however on putting too much
pressure on the folks involved to unify code bases too soon - like
say before they can actually deliver some useful code to their
existing user base. The initial aim of the project should be to grow
a community of developers and *users* around the collective codebase;
code reuse is secondary IMHO.
Please remember, we're talking a large technology scope here; generic
orchestration engine (state machine / pi calculus stuff), BPEL 1.1,
BPEL 2.0, human workflow, tooling etc. Its fine for there being
different implementations of similar things if thats what the
community wants.
For those long time Apache folk here, I'm very worried about Ode
turning into another Avalon if we try and force there to be *just
one* engine (I'm not even sure if there can be just one engine, just
like there can't be one XML parsing library). I'm sure everyone
involved in an ideal world would like just one implementation of
everything; but lets try to get there calmly and without undue
pressure with the knowledge that its OK to diverge if it makes sense
as there are many different ways to solve this problem together with
a wide range of user requirements in this space.
e.g. if we ended up with 2 engines with different features doing
things differently for valid reasons and sharing some code and - more
importantly - the developers of each engine share ideas openly with
each other, then that will still be a big success IMHO.
I'm glad to see the two seed organizations be so
willing to cut-n-chop to make that real; it bodes really well for the
success of the project!
Agreed - but lets not put unnecessary handcuffs and restrictions on
the folks involved; lets encourage code reuse but allow diversity to
flourish too.
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
