river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Board Report is due...
Date Mon, 16 Mar 2009 01:28:40 GMT
On Sat, Mar 14, 2009 at 7:34 PM, Gregg Wonderly <gregg@wonderly.org> wrote:

> What I think is interesting is the continued conversation about the code.  I
> am really troubled by this, because, I personally have no problems looking
> through the code and making sense of it.  I don't think that the code has
> problems as much as the developers' visible APIs are not "like everyone
> elses way of doing things."

Agree. The question is then; "Why should we ask the developer to
struggle with the 'not like everyone elses'?"

My PoV is not a rewrite in the sense of chucking away all the code.
That is plain stupid, since so much effort has gone into ironing out
small and subtle corner-cases. My argument is to chuck away everything
non-conventional, and move towards accepted approaches of
embeddability and away from RMI Activation.

 1. Testing;
    - All tests under the main source tree.
    - All tests can be run with a directive to build system.
    - Break tests into unit, function/integration and specification suites.
    - All unit tests are run on every build.

 2. Usability in a development environment;
    - Simplify development, not by creating fancy new frameworks on
top, but having "Abstract Test classes", "Maven artifacts", "Security
Usecase" and "Simple Configuration" (see point 4 and 6), so that it
becomes easy to create your own River-dependent project.

 3. Architecture;
    - Currently there are some cyclic package dependencies. Clean that
up and modularize the build to enforce it not to re-appear.

 4. Configuration;
    - Leverage existing systems on the market.
    - Drop the in-house, funky programming language (if keep, then
move to an existing scripting language)

 5. Transports;
    - JERI becomes a separate sub-project, with its own release artifacts.
    - JERI becomes the primary and supported transport.

 6. Security;
    - The current model is very complex, and potentially too flexible.
    - I suggest to simplify a couple of common usecases.

To me, the above is more than a handful and with the current paralysis
to act, and those suggesting to act being shot down for any number of
reasons, my suggestion is that the current 2.x is 'maintenance' and a
new trunk is opened up where active development has no restrictions on
compatibility and completeness.

> Others things can be done on top of the core.  The fact that so many others
> have done this speaks clearly, for me  to the separation points that the
> current River/Jini APIs provide. Jini should really be viewed as a platform,
> not as a "solution" or "service".

Well, viewing ServiceDiscoveryManager as "on top of Jini" is perhaps
an too extreme position. I would toss that into the bucket of "Must
Have". In fact, *I* would like to conceptually merge -core and -ext,
but doing so by creating many individual codebase modules.

> We can also just sit around and say that rewriting it or making something
> different or forking would solve all our problems.  I'm not convinced that
> those choices do anything except further fragment the concepts into even
> more ways of doing similar things with no interworking standards.

"Interworking standards" ?? Uhhh... Sorry to break it to you, dude,
but Jini is not a standard interoperability platform... ;-)

Any fork, that manages to be spec compliant should be no material
problem to the technical side of Jini. However, forks dilute resources
(people, time) and very unfortunate if that becoming the case. In
fact, seeing all these 'add-ons' is indicative to me that community
fracture was built-in to the Jini game plan from the beginning, and it
may be that we are paying the price for that right now.

http://www.qi4j.org - New Energy for Java

View raw message