[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.koi] Re: Ever consider tuplespace/tspaces?
|
- From: dudeUnit <yoduderoo@xxxxxxxxxxxx>
- Date: Tue, 02 Dec 2003 18:39:37 +0100
- Newsgroups: eclipse.technology.koi
- Organization: EclipseCorner
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1
To my knowledge,
JavaSpaces is not an endorsed API but rather a tuplespace implmentation
developed in the context of Jini. I do not think one can divorce
JavaSpaces from Jini as it is a Jini service.
Important to realize is that JavaSpaces is not a standard but one of
several legitimate implementations of tuplespaces available in Java.
I have been thinking lately that a standard tuple API is just what Java
needs! But that's another bottle of beer!
If there were a standard tuple API, it could be left to the deployer to
decide which tuplespace product was most appropriate: TSpaces,
JavaSpaces, JXTASpaces, GigaSpaces, LIME, etc.
In my original post, though, I was mainly discussing the tuplespace
model, not a particular implementation. In Koi, it would presumably be
hidden behind a Web Service interface, safely abstracted away.
Mark wrote:
> Just to make sure we are not re-inventing the wheel...
>
> The JavaSpaces specification is an officially endorsed Java standard and is
> based on the TupleSpace research project. How does TSpaces differ from the
> JavaSpaces spec? Should another Java TupleSpace implementation be designed
> and architected when the existing specification is simple, robust,
> performant, and relatively mature? Perhaps koi should leverage an existing
> JavaSpaces implementation?...
>
> - Mark Figley
>
> "Tim O'Connor" <Tim_O'Connor@Instantiations.com> wrote in message
> bilevj$odi$1@eclipse.org">news:bilevj$odi$1@eclipse.org...
>
>>y'all:
>>
>>dudeUnit wrote:
>>
>>>An async comm model supporting events and decoupling of tasks with
>>>persistent shared buffer - sounds like what you are doing and also
>>>quite similiar to the Linda model.
>>
>>Interesting take on Koi. And quite the compliment! I used to be a proud
>>wearer of an "I Love Linda" button years ago when I worked for a small
>>(never to get large) supercomputer startup named Cogent Research. Our
>>whole architecture was Linda based and quite a joy it was to work with
>
> her.
>
>>>I was wondering if I should prototype a tuplespace server for Koi.
>>
>>Definately! You're correct, they are a good match. A tuplespace server
>>should be a fairly straight-forward project. Please keep us posted.
>>
>>A thought: Have you given any thought to distributing the tuples
>>amongst cooperating servers? That would be one way to cut down on the
>>bottle of having a single tuple server. Each "out" operation would place
>>the tuple into the space of several servers. Each "in" operation would
>>take it from a single server with that server notifying the others that
>>the tuple should be removed. A "rd" would, of course, leave the tuple on
>>all servers.
>>
>>to'c
>>---
>>Koi
>>A Collaborative Infrastructure for Eclipse Tools
>>http://www.eclipse.org/koi
>>
>
>
>