river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman" <nic...@hedhman.org>
Subject Re: Split JavaSpaces and JINI
Date Wed, 10 Dec 2008 02:07:32 GMT
On Tue, Dec 9, 2008 at 11:53 PM, Gregg Wonderly <gregg@wonderly.org> wrote:

> JavaSpace is an interface.  That is the definition of a JavaSpace, plain and
> simple.

No, that is incorrect. It is a semantic contract involving interfaces,
the now infamous entry classes, exceptions, remoteability, and
workflow (including an optional transactional workflow).

> If you want to take outrigger and augment it with other APIs so that it can
> provide access to the space through other means, that's something to debate
> here.

Right now, JavaSpaces API(!) is bound to Jini Entry API and Jini
Transaction API. To create a more generic Spaces API, both Entry and
Transaction should abstracted into two bits, the generic semantic
contract and the Jini-specific part (Entry may only be generic as it
is fairly simple).

I don't see the above as neither complicated nor undesirable.

For instance; Assume for a second that we have these implementations
in place, and that they are runtime swappable. In my code, I can now
have a much leaner Test setup, which are likely to execute a lot
faster and have less dependencies on the actual OS and network it is
running on.

Opening up Spaces as a programming model (at local VM level) is
another benefit, and I disagree with those that "Well, you can whip
that up in a few hours on your own", and point out that "Yes, you can
do that with most things, such as String, HashMap, Logging and a
Inversion Of Control framework such as Spring." But we don't, because
it takes longer than a few hours in reality, and we have better things
to do if those things are 'just available for use' when I need them.
Look at Apache. How many utilities can you find here that are useful,
yet the basic implementation (when all the flexibility stuff has been
stripped off) can be done in a seemingly short (hours) time frame? My
guess is hundreds. This discussion is revolving around adding to that

> Jini, needs to have a JavaSpace in the distribution, and adding more
> interfaces and complicating it, in that way, is what we should be under
> discussion, not "taking javaspaces out of jini".

I agree that JavaSpaces in its current form (the distributed one
backed by Jini) is and should be a central and integral part of River.
I would even like to see that it is expanded from the current 'single
node' to a full 'cluster' without single-point of failure, but that is
a different discussion. (In ASF terms; Spaces/JavaSpaces subproject
will stay in River until its mission and community is clear and
different enough to be its own project.)


View raw message