River's primary feature is network based communications and long running
services with "compatibility" as a "key behavior" that makes things continue to
work. The original RMI implementation was unchangable from the outside. The
addition of JERI made "communication protocols" a deployment decision. However,
discovery still has to be "compatible" and we need to make real effort on
"namespace" compatibility after the "switch to org.apache". People will be
forking river right and left and contributing nothing if we don't try very hard
to "worry about compatibility" and "make it happen when at all possible".
These are not desktop applications that get replaced by individual users
randomly so they can take advantage of upgrades when they want. This is about
network based services with broadcast client deployment via ServiceUI, much like
a web page is. Since river is "infrastructure" and not "the service", we need
to help users experience minimum impact on their deployments so that they can
easily adopt new releases of river that include bug fixes for example. The work
that Patricia is doing to shake out transaction manager misbehaviors and
probably leasing issues too, is the kind of "fixes" that we want everyone to be
able to "accept" with "trivial compatibility issues".
Gregg Wonderly
On 11/24/2010 8:40 AM, Sim IJskes - QCG wrote:
On 11/24/2010 03:11 PM, Patricia Shanahan wrote:
If we had started a formal vote, the qualification might indicate that
we had not yet done enough discussing. I suggest we continue discussing
a little longer, and then call a vote. We will probably be able to reach
a consensus proposal that will get a lot of definite positive votes.
I'm aware off the differences between a formal and a informal vote. A informal
vote however is a clear indication how one will vote when a formal vote is
called.
I can understand you want to go throught due process in determining what we are
going to do. But my personal impression from the mailing list archives, is that
the river project is completely gridlocked in subtleties. I'm not saying that
something agreed has a lifetime of infinity, but we have to start somewhere.
That means quick, decisive action, while keeping our options open.
Suppose we declare to support 1.4, 1.5, 1.6 and CDC. How do we validate this? I
don't see us building a compatibity verification on short notice.
If you want to go for river worlddomination, by keeping everything compatible,
you should bring a large suitcase of money. Then you can checkout an older
revision from the repo and build something with the horde of programmers you are
hiring.
River has to grow from spurts from contributors, we are not going to win a race
by creating a swamp. I strongly believe that the current failure of river is
because of this longwinding process. We are not going to attract more young
eager bright committers if we keep on discussing the future of river or the
subtleties of compatibility.
Gr. Sim
