On Tue, Dec 9, 2008 at 11:53 PM, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
> JavaSpace is an interface. That is the definition of a JavaSpace, plain and > simple. No, that is incorrect. It is a semantic contract involving interfaces, the now infamous entry classes, exceptions, remoteability, and workflow (including an optional transactional workflow). > If you want to take outrigger and augment it with other APIs so that it can > provide access to the space through other means, that's something to debate > here. Right now, JavaSpaces API(!) is bound to Jini Entry API and Jini Transaction API. To create a more generic Spaces API, both Entry and Transaction should abstracted into two bits, the generic semantic contract and the Jini-specific part (Entry may only be generic as it is fairly simple). I don't see the above as neither complicated nor undesirable. For instance; Assume for a second that we have these implementations in place, and that they are runtime swappable. In my code, I can now have a much leaner Test setup, which are likely to execute a lot faster and have less dependencies on the actual OS and network it is running on. Opening up Spaces as a programming model (at local VM level) is another benefit, and I disagree with those that "Well, you can whip that up in a few hours on your own", and point out that "Yes, you can do that with most things, such as String, HashMap, Logging and a Inversion Of Control framework such as Spring." But we don't, because it takes longer than a few hours in reality, and we have better things to do if those things are 'just available for use' when I need them. Look at Apache. How many utilities can you find here that are useful, yet the basic implementation (when all the flexibility stuff has been stripped off) can be done in a seemingly short (hours) time frame? My guess is hundreds. This discussion is revolving around adding to that tradition. > Jini, needs to have a JavaSpace in the distribution, and adding more > interfaces and complicating it, in that way, is what we should be under > discussion, not "taking javaspaces out of jini". I agree that JavaSpaces in its current form (the distributed one backed by Jini) is and should be a central and integral part of River. I would even like to see that it is expanded from the current 'single node' to a full 'cluster' without single-point of failure, but that is a different discussion. (In ASF terms; Spaces/JavaSpaces subproject will stay in River until its mission and community is clear and different enough to be its own project.) Cheers Niclas
