Gervas Douglas wrote: > I have never heard a single simple convincing explanation for why no tuple > spaces implementation has taken off. > hi,
one data point from my own experience: writing non trivial applications that *uses* tuple spaces is hard (that is irregardless of implementation or tuple space API design). tuple spaces are very nice when considered as an idea (and their potential ...). in particular as they decouple processes that use tuple space(s) that may lead to more resilient to failure and scalable applications. however programming such processes and coordinating them into a coherent and maintainable application is not an easy task - in a way pub-sub APIs has an advantage as they provide more restricted but flexible _enough_ model for many applications and still are providing enough decoupling whereas tuple spaces provide even more freedom but then one needs to provide higher level protocols on top of low level tuple space operations and that is hard ... best, alek > JavaSpaces was undoubtedly stillborn due to Sun's senior management's > failure to see its significance (not being integral part of a SPARC > chip?). TSPaces is more of a puzzle: why were the lads at Almaden > abandoned by IBM, a company which supposedly has some comprehension of > infrastructural software? Was it due to internal rivalry (competition > for DB2?), or did IBM decide it was so valuable they would keep it for > internal use? I have never heard anyone suggest that the product was > rubbish. > > I don't see why a tuple spaces package should be seen as direct > competition to a DBMS - if they are, perhaps the users do not > understand their respective strengths and weaknesses. You mention the > big boys backing alternative solutions with big bucks, but that in > itself does not preclude an innovator coming up with a disruptive > competitor based on tuple spaces. > > Gervas > > --- In [email protected], "Michael > Champion" <[EMAIL PROTECTED]> wrote: > >> On 4/13/06, Elias Sinderson <[EMAIL PROTECTED]> wrote: >> >> >>> Indeed, and the conclusions no less relevant now than they were >>> > when it > >>> was published -- did you even read the article? :-) FYI, here is a >>> more recent paper published out of the TSpaces group: >>> >> I read it (or a similar paper on TSpaces) about 4 years ago :-) FWIW I >> really did buy the "sweet spot" argument in section 1.1 of that paper. >> My only question is whether others still do? Technically, I like the >> idea very much-- "loosely coupled in location, platform, and time" is >> how I remember Patrick Thompson (or Ruple fame) describing the basic >> design pattern. >> >> The non-technical problems I see are: >> - The web (now that most serious sites are backed by DBMS) plucked the >> low hanging fruit. I can reserve hotel rooms, synch my cellphone with >> Outlook, etc. etc. over the web now, maybe not as cleanly as one might >> with J/T/X-Spaces, but some VC or telco has put up the big bucks to >> make these things work by brute force. >> - Worse is better -- The value of the web's network effect overwhelms >> its kludginess (sorry Mark, no +1 from you today!) as a platform for >> the kinds of apps that J/T/X-spaces envisioned. >> - WS-* grabbed the mindshare among people who have enterprise-class >> problems to solve that are too difficult to kludge around with raw >> HTTP+XML. >> >> I would be very happy to be wrong on the non-technical issues, but >> need some evidence that they are being overcome before I can get too >> excited about this stuff again. >> >> > > > > > > > > > > > Yahoo! Groups Links > > > > > > > -- The best way to predict the future is to invent it - Alan Kay Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
