On Sat, Dec 20, 2008 at 6:21 PM, Dan Creswell <[email protected]> wrote:
>> I am NOT your regular newbie; I adopted Jini 1.0/1.1 in a critical > > Alas, some of what you're saying suggests otherwise - sorry if that's > hurtful but see my comments above re: remote vs local. Perhaps you do > understand this stuff and we're just having a communication problem owing > to words used? I agree that I am newbie to Jini 2.x, no doubt. But I think it is largely a communication problem. My *biggest* issue is that Jini is not test-friendly one single bit. On top of that, it is not friendly to integrate Jini into other open-development projects. But when I speak of an in-JVM entry point, I mean many things, but NOT abandoning the network-centric view of Jini; * In-JVM implementations that are easy to deploy, don't involve network interfaces (which opens a can of testing issues), and possibly even have the capability to simulate various network failures. * I think I understand the Remove Event specification, and why RemoteListener exists. That does NOT prevent the client listener to the space to be a local interface with a semantic-centric meaning. It simply builds on the spirit of the local smart proxy, that I think is probably the best thing with Jini. * A lot of discussion has been revolving around an in-JVM JavaSpaces implementation. I don't agree with McGrady's viewpoint other than that I think there should exist one, and that is a drop-in replacement (i.e. no client changes needed). I do think that promoting the JavaSpaces programming model, in combination of both many implementations, from the simplest to the most extreme, is a good 'portal' to increase users of River technology. And I expect that there will be rub-off effects from "In-JVM JavaSpaces" to full-fledged Jini technology. >> * "Jini is an 'all-or-nothing' commitment.", which requires >> decisions higher up in the organization, instead of developers. Such >> strategic decisions are made at the golf course or over a $1000 >> dinner. We must provide in-JVM entry points and ride well inside > > Sure, provide local entry points but don't think for a second you won't > have to change the code when you go remote. I somewhat disagree. If you present a programming model with "NonAvailability" and "CallFailures", many programmers can code against such semantic model. Even more so, if it is reliably testable (which the network setup barely can provide). Now, my experience with Jini 1.x, resulted in a drastic change in the view of how to write the application as a result, since failure on every single method call is just too much to deal with. Instead, more events and workers. But, I kept that style of programming years after I stopped using Jini actively, because it often made sense. > That assumes that the containers in question actually have a permissive > environment. Most don't - I know this as I've had to build a new > classloader model this week to work around JBoss's classloader mess that > doesn't allow multiple versions of code to co-habit at all well. This > same kind of issue makes Jini integration hard. Bingo! Everybody that messes with classloaders will of course blame the other party that an integration doesn't work. Jini is no exception, of course it is the other party. Perhaps the 'vision' of JiniNextLevel is all about better integration especially in terms of classloading (which I must say accounts for a fair bit of problems in many cases). I have previously promoted embracing OSGi as the classloading model used, but that went pretty much on deaf ears before. I still think it makes sense, but won't put up a fight over it again, and probably doesn't solve container integration for now. So, Dan, you have my utmost respect, and I am not here to diminish, destroy or ridicule your and others excellent efforts over the years. On the contrary... If we don't act within the next 6-12 months, I fear that River incubation will be over, the shop closed and no strength left to move it elsewhere, and Jini will fade away on the pages of the history books. All that effort going nowhere sounds like a stupid idea. One more thing; A very common "theme" is; X: "I want to ..." Y: "Well, that is not built-in, but take a look at ..." I guess that is actually a VERY GOOD thing. I can start with something higher up the technology stack. BUT the bad thing is; I now have 30 different projects to contend with, and only the effort to figure out what could be useful, where is it, and how it would fit into a bigger picture will take too much of my time and I'll leave before starting. So, I would like to propose that many of these useful projects are brought into River, unified into a single source of "Good Stuff". It would create a better 'view' to the world what River is all about. Perhaps we should even promote the higher layers primarily, and Jini Core becomes an underlying component that people don't need to know the details about. Does anyone have a comprehensive list of projects (and a short description) that are candidates for this? I think I will spend a few more cycles on coding over the holidays, and see if I can create myself a proposal to changes... Cheers Niclas
