I think like that too.
Once we have a modular build, hopefully this will be easier to
determine, I'd like to have my cake & eat it too. :-)
The use of concurrent language features should be part of implementation
rather than our public API, so in theory at least, the jvm local
components can utilise the latest language features and run on the
latest java platform while remaining network compatible with older
platforms and releases.
I guess it depends on how much work will be required.
I'm hoping we'll gain a better understanding as we work towards a
modular release.
Concurrency is the future, at some point we've got a bullet to bite.
Cheers,
Peter.
Patricia Shanahan wrote:
I have a constant tension between two ways of thinking.
As a programmer, looking only at the best way to fix bugs and make the
software faster and more reliable, I sorely miss JDK 1.5 and 1.6
features, especially java.util.concurrent etc., which makes concurrent
programming much cleaner.
On the other hand, I've interacted with people managing large
networks, and software developers who distribute their products to
organizations with large networks. Those two audiences tend to be
extremely conservative. Supporting an infrastructure software release
is a big deal, with enormous testing costs. Moving to a new release,
especially if it has to be done simultaneously on multiple systems, is
a major project, with months of planning and preparation.
I am having a lot of trouble even deciding on my own position on which
releases to support.
I would like to start a sub-project, perhaps as a Wiki page, on
writing a migration guide. If we can't come up with a good plan for
using our release strategy in a large network, we need to rethink the
release strategy. If we can, we should document it and ask the user
mailing list to review it.
Patricia
Gregg Wonderly wrote:
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
