river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Split JavaSpaces and JINI
Date Thu, 11 Dec 2008 21:26:31 GMT

On Dec 11, 2008, at 1202PM, Niclas Hedhman wrote:
> 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...

Okay fine. You dont want to be bother with the details. You want to  
use a technology that can get you to dynamic distributed greatness  
without dealing with the details. Press the big green button and  
presto it just works. You are a now rock star, you can now revel in  
how you faced and battled the fallacies of distributed computing :)  
Nothing wrong with that.

The only issue I have with this is not that this sort of stuff isnt  
needed, but is it needed in River?  Alot of these issues have already  
been solved outside of the River distribution. Why should River be the  
vehicle for this? Why not have River reference the successful  
technologies that use it? Why re-invent?

For me, its how I think about River and as a project, and as a  
technology. I see it as an infrastructure that can be used to craft  
distributed systems and not _the_ technology and/or singular project  
that you use to make all of this (the laundry list of requirements &  
rants) happen.

Having been part of a company that based it's product on Jini, and  
also been part of more then a few efforts that use Jini in a multitude  
of areas, I have seen that Jini plays best when you dont see it. That  
right, when its an integral _part_ of an architecture, not when its  
_the_ architecture. Its the glue that holds it together, it provides  
the core capabilities and semantics that allow you to craft  
distributed systems using Java.

So make it easy? Hell yes. Its something that we have tried to do with  
projects like Rio, Seven, Bantam, Glyph, Harvester (and others I cant  
recall right now...). Shoe horn it all (back) into River? Just doesnt  
make sense to me.

I still maintain that going forward, a River core (discovery/join,  
lookup, leasing, transactions & distributed events), with sub-projects  
starting with JavaSpaces may be well placed for this project. Perhaps  
the other services can be voted on for inclusion as well.

One last thing: how about AR2? Can AR2 be rolled out so we can take  
advantage of the great work that has already been done by many?



View raw message