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?
Cheers Dennis
