Niclas Hedhman wrote:
On Thu, Dec 11, 2008 at 12:13 AM, Gregg Wonderly <[EMAIL PROTECTED]> 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
