river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Split JavaSpaces and JINI
Date Thu, 11 Dec 2008 22:02:07 GMT
----- Original Message ----

> From: Dennis Reedy <dennis.reedy@gmail.com>
> To: river-dev@incubator.apache.org
> Sent: Thursday, December 11, 2008 4:26:31 PM
> Subject: Re: Split JavaSpaces and JINI
> 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.

My thoughts are there should always be a core, but that doesn't mean that things used in extensions
and products should never come to the core. I bet there are many things we can find that have
been done over and over in those Jini consuming projects. Those things are the first things
we should be looking at for coming up with an enhanced and better Jini core, and that doesn't
mean we have to have a monolithic build artifact, we can have multiple jars which can be included
and excluded. Plenty of code to review.

Too, the core should really provide some out of the box stuff so folks can get started with
it. Just because it is a core doesn't mean it can't have some pretty good runtimes and libraries
and tooling that *just works* out of the box, and the extensions can still have their value
adds. Just, why rewrite and maintain the same things in all the different products? Might
as well pull commonality into the core. I like the things from Gregg's last reply to Niclas'
points as well.

I don't think jsk-platform.jar makes that much difference. Seems we need some things in separate
JARs such as interfaces in one, some other things in others maybe. Especially when we start
pulling in commonality. Services would be their own things as well. Build system can break
that up too, whether it be Ant or Maven.

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

Think I saw some questions on this before in the thread. Where is everyone with the code they
were working on? There was talk about not switching the namespace etc to River until those
things were done.


View raw message