river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: SourceAliveRemoteEvent Part II
Date Thu, 07 Jun 2007 08:59:40 GMT
Christopher G. Stach II wrote:

> Mark: "Yeah, I think this could help a lot of people in the community."
> Sun: "No.  I didn't think of it.  Useless."

I think that should be "Bob: ... Useless." (the dots are there for
brevity not to make the sentence imply something :-). It is not
illogical for the Sun committers to have some form of 'Hive Mind', but I
don't believe Bob is acting as a proxy for the others.

It would be nice though if we had a sign of either an ACK of Bob
discouraging responses or even better ... signs of diverting Sun
committers ;-)

> I hope that River has more going for it than just taking over the code
> from Sun and letting it rot.  Nobody is going to win by having the raw
> implementation of a relatively basic set of constructs.  It's going to
> succeed by having value added to it, and that value comes in many forms.
>  Keep Jini standard, but let River make people's lives easier.

I think what plays a role here is with how one can look at Jini.

Assume a person says "Jini sucks", well my next question is always "Do
you think the concepts are useless and the implementation of those
Specifications. Or do you think it is a horror to build and configure a
software system based on the Sun distribution called the JTSK". If the
answer turns out to be the latter I can agree and that means there is
room for improvement, but it seem Jini as Specification/implementation
is fine. If it is the first well than it is "Houston we have a problem".

If you were able to see the JTSK separate from the concepts and the code
implementing the Specifications and give that latter a name so that you
could see it as a noun I think we are heading the right way. Assume we
have something as the "Jini Platform" which is in short the Jini Core
Platform (that existed in 1999,
http://www.sun.com/software/jini/specs/jini1.1html/core-title.html) plus
the latest security stuff including Jini ERI.

Suddenly we have our 'sacred noun' around which we can dance and on
Harvest Day offer one WS-* spec lead. So the "Jini Platform" will
consist out of substantial API and environmental assumptions and defines
the interoperability for clients and servers (the soul to Jini). The
result of that is meant mainly for those who want to build a product
complying to the "Jini Platform" on top of that. This could be the
continuation of what the JTSK actually is, a product that allows you to
get started with the Jini concepts and build Jini compliant services
(for which you have to do a lot yourself) or you can go to GigaSpaces or
take Rio or anything else that advertises it can do that trick much
better, either for a broad spectrum or for a niche.

Well to me it seems that River can do both, the "Jini Platform"
representing the base level that enables the larger Jini community to
cooperate (in and outside River) and various sub-projects (?) that
explore different ideas. Although from a management point of view I have
my concerns, but consider that a detail.

I'm going to be clear and that is that my main interest is in enhancing
the "Jini Platform" and I see myself working on the utilities that are
useful for a broad spectrum in the Jini community (not part of the
Platform). Personally I see not much value in enhancing the user
experience of the JTSK itself, because I'm doing that already since 2002
in the form of working on the JSC Specification and Seven through the
Cheiron project and I don't believe there can or should be just one way
to develop/deploy Jini services.

I do see value in enhancing the "Jini Platform" if it turns out that
some concepts are applicable in general, such as with SARE, inverted
event model, "Jini across the Firewall". See it as the way J2EE evolves
and various projects in the world compete in providing the best possible
implementation, or geared towards an area of the specification. The main
difference is though that with J2EE compatibility is at the 'container'
level and with Jini it is at the network level, the latter of course the
stronger model. Exactly for that reason I don't believe in standardizing
a single container model, for Jini you just don't need it for other
reasons other than wrong perception.

And just be very clear, if people want to do as part of River "the best
user experience people can ever have with Jini" that is totally fine
with me. I'm not going to frustrate that, I might even advice and point
to some code you can rip for free (long live the ALv2), but having an
evolving "Jini Platform" that unites the larger world is something I
really value and that represents to me the soul of this project.

View raw message