Hi, I am new to this list but willing to contribute to River. So I can equally start by sharing my thoughts on the subject.
The key point is that JavaSpaces API is not _just_ Java Linda spaces API - JavaSpaces is _distributed_ Java Linda spaces API. The JINI way of designing distributed systems is: - not hiding distributed nature of the system (hence RemoteException) - leasing - distributed transactions - remote events - dynamic code downloading I cannot see anything you could simplify in JavaSpaces without going against the core principles behind JavaSpaces API being designed _exactly_ the way it is designed. You can remove the "JINI" label from the interfaces net.jini.core.lease.Lease or net.jini.core.transaction.Transaction but what is the point of doing so? Michal On Wednesday, 10 of December 2008 15:23:21 Michael McGrady wrote: > Good morning, John. > > My predilection is to make system architecting suggestions or > decisions first rather than systems engineering specifications, being > artfully concrete rather than scientifically. So, I hope the > following is sufficient for your request. > > Imagine you want to create a Java Linda spaces API. You want > JavaSpaces to work and you want to simplify, simplify, simplify - to > forget the bells and whistles for a bit. What it takes to do that > would "belong to JavaSpaces". This would seemingly require spaces and > entries and operations on entries required by the architecture. > > I suspect Niclas is taking a stab at this now and I am very interested > in his results. > > Mike > > On Dec 10, 2008, at 8:45 AM, John McClain wrote: > > Michael McGrady wrote: > >> This is just to allow JavaSpaces to live its "natural life" and to > >> move what is in JINI but belongs in JavaSpaces to JavaSpaces so > >> that a Java implementation of Linda spaces can stand on its own. > > > > Can you be concrete about what "belongs in JavaSpaces", and how this > > move would happen? > > Michael McGrady > Senior Engineer > Topia Technology, Inc. > 1.253.720.3365 > [EMAIL PROTECTED]
