On Fri, Dec 12, 2008 at 12:30 AM, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
> 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. Ok, let's try this again; I want the 'package' that is offered to "me" to have local-JVM implementations that are plug-replaceable with distributed ones. I don't want to "yank" out Transactions and Leases, I want to be able to use them easily locally without network traffic. I want an introduction path into this world going through that 'local-JVM' variant first, and slowly introducing the more complex aspects of Jini to me. I don't want to know that I have 3-4 transport protocols, some with endless options, and I don't want to know the details of setting up security (just assume I am the ignorant b'stard that I am and give me AllPermissions until I sober up). I don't want to see configuration files in a "Java-like" language, either give me a straight shooting API, properties files or worst-case a Spring app context... I want to deploy my first Jini services and clients in a WAR on Tomcat, without having to ask my NetAdmin to alter any setup and know that it works out of the box everywhere. I want services to be under the control of Java code that I write. I don't want to ever hear about RMID and Activation ever again. I don't want to encounter classloading problems when services are in the same JVM, even if they depend on different versions of Jini "Core". I want every bit of the system to be Maven adapted, so that my Maven project can consume the meta-data easily. Jini is a toolkit, and not a installable application for JC's sake. I want to be able to use Jeri without any Jini at all. I want to be able to easily(!) test my Jini clients and services within a single JVM (otherwise too hard to automate), preferably via a single AbstractJiniServiceTestcase and AbstractJiniClientTestcase doing all the bits for me. And of course, those take care of whether I am testing against InMemory or OverNetwork versions of the services. I want River to 'feel' like an open source and accessible project. Simple things should be dirt easy and complex things should be possible. I _might_ want to chuck the Configuration system, or at least create more familiar alternate implementations. Well, that is what I can recall after midnight (now)... Maybe more later... Does that help, or am I still confusing? Cheers Niclas
