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.
There are two types of compatibility:
Local Installation Platform.
Remote Distributed Environment Communication.
Jini is the end of protocols, the advantage of a protocol is, your not
tied to different platforms, the disadvantage is your locked into your
protocol. With Jini / River, the bytecode our proxy is compiled with,
is our protocol.
It looks like the easiest option for our current release is (users can
skip this release if they need earlier remote platform support):
Local Installation Platform - Java 6
Remote Distributed Environment Clients - Java 6
Remote Distributed Environment Services - Anything that can a register a
java proxy with a previous release lookup service, if available, or a
Surrogate running on Java 6, or a Service running on Java 6.
With a modular build this will be possible:
Local Installation Platform - Java 6
Remote Distributed Environment Clients - Java 1.4, 5, 6, CDC
Remote Distributed Environment Services - Anything that can provide a
java proxy.
In fact, if the Service API and proxy's are compiled to be Java 1.4
compatible, then we simply unit test the proxy classes on Java 1.4, and
check the serial form of our objects hasn't changed as part of testing
that module. We don't need to make it complicated. The module jar
files will be used in the qa integration tests for the supported
platform, Java 6.
Each service will have at the minimum two modules, three for Services
with smart proxy's:
1. service_name-api.jar - Compile for / with Java 1.4
2. impl_name-version-imp.jar - Compile for Java 6
3. impl_name-version-proxy.jar Compile for / with Java 1.4
* 2 and 3 depend on 1.
* 2 depends on 3.
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.
As developers we need to understand the subtleties of compatibility, we
can provide best practices for our users, so they don't have to
understand the subtleties.
Don't forget the fallacies, we can't ignore the compatibility issues, we
need to work out how to best handle them, then document for users, our
best programming practices, so they can avoid the issues.
We need to be able to make it easy for user developers to utilise River,
if we ignore the issues, we'll just make it harder.
I agree that we need to be careful about how we discuss the future of
River and compatibility, but I don't agree that would should stop
discussing it. I'm not about holding up progress, I recognise we have
limitations and cannot support everything, but we don't want to remove
the possibilities either.
I don't see failure or gridlock, I see progress in leaps and bounds and
some difficult things we haven't done yet, that we're working out how to do.
I also recognise the significant efforts you've all contributed has made
graduation possible.
Cheers,
Peter.
