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. > import net.jini.core.lease.Lease; ^^^^ HERE ^^^^ Leases are a good thing. But again, without a light-weight implementation, it makes my day miserable. > import net.jini.core.event.RemoteEventListener; ^^^^ HERE ^^^^ This is probably controversial; Jini's use of local smart proxies is brilliant, so why is not this fact used much more in the specifications. Why are network protocol details shining through everywhere? The notify() method should (of course? obviously not) take a SpaceListener at the local interface level, and use the RemoteEventListener hidden on remote interface. Sorry to say Gregg (and others), I am getting really frustrated with the "There is nothing wrong!" attitude from 'old timers', when clearly the most clever technology have been unable to conquer every Java developer's mind and toolkit, and having had 8-10 years to do so. I am NOT your regular newbie; I adopted Jini 1.0/1.1 in a critical application in 2001, where we ran both clients, servers and 'device drivers' both locally and across the Internet with full blown Jini infrastructure. At that time, it was 'somewhat painful' to get things operational. When I now return (as a complete 2.x newbie), I notice that things are still hard, perhaps even harder. Meanwhile (6 years!), I have gone from a heavy and slow development process, to do things much, much more light-weight and test driven. And when I now try to integrate Jini into an open source framework I am working on, it gives me more pain than I could imagine, mostly due to how hard it is to get tests working. Sorry, but the whole Jini "setup mentality" is just wrong. Calum; Stuff like Glyph --> Excellent, things in the right direction, but it doesn't solve the underlying problems; * "It is HARD to use Jini and/or Spaces in other projects". Maven artifacts are becoming the preferred choice by many. How do we meet that? How can I Jini enable (for instance with Glyph) and still test that it works in a Jini environment, and not only relying on Calum saying "Don't worry, it will!". * "Jini HAS FAILED to capture the developers' minds.", and I don't care how much people here will jump up and down claiming that that is not true. * "Jini is an 'all-or-nothing' commitment.", which requires decisions higher up in the organization, instead of developers. Such strategic decisions are made at the golf course or over a $1000 dinner. We must provide in-JVM entry points and ride well inside Tomcat and other containers, without requiring changes to neither the JVM nor the container. Such feature should be advertised up-front and not something one needs to go digging for whether it is at all possible. Well, I will stop arguing about what I think is wrong, and just go out and make the changes I think is necessary. And funny enough, it is not that much that needs to be changed. If I am not welcome to do so that here at River, then fine, I bring the codebase elsewhere. Cheers Niclas
