Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4941402C.7050405@cox.net>
Date: Thu, 11 Dec 2008 10:30:36 -0600
From: Gregg Wonderly <gergg@cox.net>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Split JavaSpaces and JINI
References: <964EAC824495234A86F3C47DA8BD8AAD17750A@sucden-exch.sucden.co.uk>
	 <bb2708720812071852j711decc2m62f3475129e12fed@mail.gmail.com>
	 <F6F6F89E-A8CB-424A-AA40-2CE5C3500C53@topiatechnology.com>
	 <493D40A9.7020808@wizards.de>
	 <863EA217-8B6B-4881-867E-8A645A036276@topiatechnology.com>
	 <493D77B0.5060803@wonderly.org>
	 <caf30e2a0812082235v1259a654r840eabc0c151329d@mail.gmail.com>
	 <493E9460.1030901@wonderly.org>
	 <caf30e2a0812091807u20b45c02yfd69108259902d12@mail.gmail.com>
	 <493FEAA1.7030708@cox.net>
 <caf30e2a0812101858t1fba4351q907c0c5d5a3c4f5d@mail.gmail.com>
In-Reply-To: <caf30e2a0812101858t1fba4351q907c0c5d5a3c4f5d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Niclas Hedhman wrote:
> On Thu, Dec 11, 2008 at 12:13 AM, Gregg Wonderly <gergg@cox.net> wrote:
> 
>> Help me understand please!
>>
>> import net.jini.core.transaction.Transaction;
> 
> ^^^^ HERE ^^^^
> 
> JavaSpaces depends on Transaction. Perhaps you think it is rudimentary
> simple to implement a Transaction system that are semantically
> accurate with the Jini Transaction Specification at in-JVM level.

Okay, I sense that you think that the fact that there is not a removable 
dependency, that there is a problem?  I'll ask the same question again.  If all 
I need in my java application is a bunch of strings, should a jump up and down 
and stomp my feet and throw a fit that I can't get a JDK release with just 
String in it?

The JavaSpace API is about supporting the spec.  Everything in the spec results 
in adding particular value that makes it work.  Is there complication?  You bet? 
  Can it be simplified?  I think there is some chance to provide some 
simplication for specific use cases, but you can't just yank out Transaction and 
Lease and say now we've made it better.

I see that you've used some form of Jini (the old primitive 1.X) for a while. 
When you got to 2.x, you found that there was even more to learn and things had 
changed, from your perspective, to not be simpler.

So, maybe instead of talking about what to yank out of what, we'd be better off 
changing the conversation to what attributes of the Jini system do we want, and 
what attributes are not adding value.  And by attributes, I don't mean chunks of 
code.

Perhaps Niclas you can enumerate all the reasons why JavaSpace shouldn't have 
transactions or leases?

I'm dead serious about trying to understand what you are saying.  All I think I 
hear is "this is too hard, I don't like it, change it or I'll fork" in what you 
type.  I don't find this to be a very community oriented presentation of your 
concerns.

Yes, there are many things which are hard to do with Jini.  It's a lot of things 
to learn, it's not just using the Java language.  Instead, you have to think 
about distributed systems issues such as distributed resource management. 
Leasing and Transactions provide the mechanisms for making sure all parties in a 
distributed system agree or can arrive eventually at an agreement (lease 
timeout) about what the state of their "world" is.

We do this with booleans and synchronized() sections etc in local JVM, 
inter-Thread processing.  Are Transactions more complicated than synchronized()? 
  Absolutely, they work remotely.  Are all applications remote?  If you 
implement a local Transaction system, does it have to meet the Jini spec?  If 
you want the world to talk to it, arbitrarily, they yes.  If you just want to 
use the mechanics of prepare/commit/abort, then I'd say it doesn't have to meet 
the specs, only your needs.  I've used Transaction in several places, creating 
participants etc.  I didn't strive to meet the spec because that's not what I 
needed.  What I needed was to use the API to meet my applications needs.

Niclas, I've written tens and twenties of different Jini based applications, 
using newer release as I've gone along.  I have countless convenience classes 
which I use to greatly simplify these large complex patterns.  I wrote a 
completely new space service (http://griddle.dev.java.net) which changes a lot 
about the JavaSpace mechanisms to create something that is in fact much 
different in that it has comparators, separated data and keys, interator and 
executor support etc.  I know this stuff is hard...

I understand that it would be great to write one line of code to do large 
complex things.  It's possible to do a lot of abstracting of the Jini framework 
into far fewer lines of code.

Can we get back to a conversation about how to simplify on top of the platform 
instead of how to completely invalidate the platform so that it fits a few 
peoples way of thinking?

Gregg Wonderly