----- Original Message ---- > From: Niclas Hedhman <[EMAIL PROTECTED]> > To: river-dev@incubator.apache.org > Sent: Tuesday, December 9, 2008 1:35:25 AM > Subject: Re: Split JavaSpaces and JINI > > On Tue, Dec 9, 2008 at 3:38 AM, Gregg Wonderly wrote: > > > Okay, I think there needs to be a viewpoint expressed here that comes from a > > different direction. Jini is not all the services in River. Jini is the > > foundation/API in River, which allows you to create clients and services. > > These utilize the Java security system, Java mobile code, and the Java > > platform, in general, to effectively (and I'd say efficiently) create > > distributed, scalable network centric applications. > > We hear ya; but relax a second, > > 1. Spaces as a concept is not bound to Jini. > > 2. A Spaces API can likewise be Jini-agnostic. > I would say considering its packages and classes and those used in method signatures it is. At least now anyways. Now, if you mean not bound to everything in Jini then sure. Such an implementation could not have everything in Jini as a whole such as services, and even some packages. I would think more modularization would fix some of that though.
> 3. Outrigger (the Jini backed Spaces implementation) *could* implement > the above mentioned Spaces API as well. > Sure, but why necessarily? What exactly is the proposal? Do you mean to just support POJOs in the lookup and you mean to get rid of Entry? > 4. A LocalSpaces implementation *could* exist for various reasons. > > 5. Other Spaces implemenations *could* exist for various reasons. > > Example; Go to www.jpos.org, which deals with Payment Gateways (VISA > et al), and you will find several local implementations of spaces as a > programming model. Alejandro doesn't need it to be distributed, but to > simplify the domain. He almost included JavaSpaces as well, but for > the reasons mentioned here (not easy to integrate seaminglessly into > other applications), he back paddled many years ago. > Yes, but per your own argument it *seems* his reason had nothing to do necessarily with the Jini APIs as much as it had to do with taking those things and bringing them in and complexity, or at least perceived complexity if not just having to include bigger JARs than someone wanted. A LocalSpaces implementation already exists, and uses the Jini APIs, just doesn't use all the services etc according to what I have read on the lists; I haven't used it, but looking at all the Jini APIs as they are interfaces and abstract classes at the lowest levels one can get an idea for what can be done. Other implementations can do the same. Whether Spaces is using Entry or some other API classes it is still an API. Take many Apache libraries such as NET. It has FTP, HTTPS, and others. Or for instance, take the virtual file system. They all have this or that API, and they depend on other things, just because you use one part of the API doesn't mean you have to use them all, but you do get them all in a JAR file. Some other things you have in other JAR files as dependencies which you never need because you don't call specific code. Gregg's point is that for a Spaces implementation, the APIs provide what one needs to use them as JavaSpaces, and to meet the specification or API level specification, and this involves more than than simple in memory Lookup. If one just needs a simple lookup and store or object/event bus type system they can find many other libraries such as NetBeans Lookup API which lets one store entries by class type (SomeClass.class) locally, or, they can write their own very fast and easy though Lookup has a lot of other things such as support for META-INF/services lookup and creation (SPI). Either way, if that is all one needs something like Lookup may be better, leaner, faster, and would fit such a Local need better than a JavaSpaces implementation, though if Jini had some other implementations in the APIs it would be just as easy to include it and use it. If they really need a Spaces implementation it is very easy to use the Jini APIs now to do all kinds of custom things. Most of them are just interfaces. For me, I would rather not try to make all Jini's libraries so broken out and decoupled that it looses its intended meaning and becomes a nightmare with no compile time checks for the use cases, which it seems we need a new JavaSpaces05 implementation which uses Generics. From that perspective JavaSpaces and the core Jini libraries and interfaces are rather simple already, and one can take any of those interfaces and abstract classes and make all kinds of custom things. If you were to try to decouple Entry and Transaction from JavaSpaces you would end up with something entirely different it seems, and it wouldn't be JavaSpaces technically, it at least would not be backward compatible, but maybe that doesn't matter so much, but I bet many of the folks with large investments in Jini will certainly think it matters. Now, breaking things out more modular and into smaller and smaller JARs I can see. Then one could take those core interfaces or other things and have smaller libraries which different custom things could be done. Seems this is a more realistic goal unless you mean to change lookup, spaces, etc all to support different templates/entries such as a POJO model or something. Of course, other methods can be added and retain binary compatibility which just provide other ways of looking up information or services. I guess the real issue with the debate is more specifics are needed such as what exactly, less breaking things out into smaller and smaller more modular units, is actually making local spaces and custom spaces harder to implement. They are JavaSpaces implementations after all and not an object/event bus only. The provided services and applications with Jini, we seem to have consensus, need to have better deployment and usability capabilities, we need better development tools, a better build system, source structure, some installers maybe, etc. So, the specifics on what these changes would actually intail, and why those things folks are wanting to do can't be done now seem more logical for proving the exact needs. I haven't seen the cohesive reason yet is the point I'm getting at here; having some extra interfaces in a JAR which holds JavaSpaces and the rest of Jini doesn't seem at all a big deal to me per all reasons stated above. I'm trying to understand, but as far as I can tell now those JARs will be small and usable if we break things out like we've been talking, and things are very customizable now though we don't have many different implementations to be used for different purposes at the moment such as a Local spaces implementation where no lookup of the space etc is needed, and maybe that is the real issue? Wade ================== Wade Chandler, CCE Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member http://www.certified-computer-examiner.com http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org
