intertwingly

(1) With Microsoft being a major player in the WS arena, how likely is it that they would ever support this idea?
(2) Why should concepts from CORBA, which is (mostly) a tightly coupled, synchronous, RPC-oriented framework, be a good match for a document-centric, loosely-coupled, asynchronous WS-style solution?
BTW, the spell-checker just rocks.

Stefan: whereas Patrick seems to only be able to think of one reason, you immediately are able to think of two.  I suspect that if you were to think about it a bit more, you could come up with plenty more.

My style is not to address such criticisms head on.  If people think that such things are so easy, I simply suggest that they Name That Tune.

Meanwhile, there are people like the developers of WSIF who are doing exactly that.

Sam,

I can usually think of several reasons for things. I usually write one startling one, because those tend to start conversations and those conversations get me to think in ways I may not otherwise. I have no end of criticism of CORBA and many are in common with WS-xxx.

As for naming the tune, I have no interest. I have participated in "standards" definitions before. They are unsatisfying for me as an activity, but I still have opinions about the process and results. Still it is more than fair to challenge me to this.

None of which means I don't appreciate all that you do, or others in your cadre. I don't have to point out to anyone that you are clear thinking and productive in the most practical sense. Would that this were the norm.

CORBA... is (mostly) a tightly coupled, synchronous, RPC-oriented framework

CORBA has taken significant steps away from this original position over the last 5+ years, esp. with CORBA 3.0.

The benefit of WS-xxx folks working with CORBA folks (and I don't know that they aren't the same folks already), is not so much in wholesale adoption of CORBA 3.0. Instead it is the incorporation of ideas and lessons learned, from both parties, into a CORBA 4.0 better than either 3.0 or WS-xxx.

If people think that such things are so easy...

Never said that.

WSIF

Nice.

FYI:

• none of the WS-xxx specs have my name on it.
• I know for a fact that some of the IBM WS folks have a strong CORBA background.

Sam,

OK --- after a few similar feeling exchanges and an hour or so after writing "I have no interest" in such things, I'm going to plug in more directly (not sure what form, open to suggestions) into some of the WS-xxx efforts that concern me.

No more shooting from the hip in this topic. I obviously have an interest in such things.

Patrick: excellent!

If you want suggestions, what I most would like to explore is what is next.  After Web Services.

I occasionally hear talk of an Internet Operating System.  And as a group we obsess on what is the optimal design of an individual neuron.

Something nagging in me tells me that these are the wrong metaphors and that we are are the wrong meta-level.  There is no brain operating system.  The emergent behavior of a brain can't completely be understood by looking at how individual neurons operate.

The future is multi-cellular.  The cell walls aren't necessarily distance, but represent trust boundaries.  It will never be the case that all data will be directly addressible.  We wouldn't want it to be.

What is next...

Maybe some people want to talk about this in Portland in July.

Here's what's next; the Web.  Again.

Mark: It will never be the case that all data will be directly addressable.  We wouldn't want it to be.

Patrick: I would be very interested in such a discussion.  I'll be in Portland in July, bouncing between OSCON and the DevCon.

The Web doesn't force you to identify all data, it just makes it sub-optimal.  That's a feature.

Mark: Is Linda the web?

It's not the Web, but it can be integrated into it. rd->GET, out->POST, etc.. just like all other inferior systems. 8-)

Mark, the key point of Linda that when I "out", I don't know who the recipient is, or even how many recipients there may be.

Treat it as an inverted web.

My RSS feed achieves a similar result despite being built upon an inferior system like HTTP, even though architecturally that seems pretty dumb.

Sam, that's exactly the same as POST.

POST w/o the URI.  In other words, it is a POST to noplace in particular.

Or are you suggesting layering the Linda verbs on top of the HTTP protocol?  HTTP is an application layer protocol after all...

I'm interested in a What's next discussion at OSCON.

Sam, my autoping to you blog is broken.  It thinks that your pingback url is

http://intertwingly.net.new.cr.sabren.com/blog/pingback

I've completed my registration for the O'Reilly Open Source Convention. I'll be in Portland from Tuesday July 8, through Friday July 11. If there's anyone who wants to get together during OSCON, please leave a comment on this entry. I know that Sam ...

Pingback from Ted Leung on the air

Pingback seems to be working now.

I'll keep track of the interested folks. I've had some email from my blog too. As the week gets closer and each of our agendas are more clear, I'll start a search for the best time slot.

Wiki page created for names of interested participants...

http://www.c2.com/cgi/wiki?WhatsNext

No, picking a URI for POST is the same as locating a tuple space on which to invoke out().

I wouldn't layer tuple spaces on top of HTTP, because HTTP already provides me a tuple-space-like network abstraction.  I may extend HTTP to provide more tuple-space-like actions, like oh say, notify()/NOTIFY/MONITOR (ala KnowNow).

Hmm.  Directing all posts to a single URI.  Implementing new verbs which are not uniformly available.  Sounds familiar.

Hmm, nope.  I think you're missing something, though I can't tell what.  Here's my model;

tuple space <-> resource
tuple <-> representation
tuple space identifier <-> URI
tuple space server <-> Web server

Mark:  Let's see if a concrete example gets to the bottom of this: Weblogs.com has an XML-RPC interface. One 'pings' it with a tuple (weblogname, weblogurl).  The resource is http://rpc.weblogs.com:80/RPC2.  The weblogs.com identifier is clearly a URI.  And the weblogs.com server is clearly a web server.

Given that these two things are apparently isomorphic, I am having a hard time understanding why you have a visceral reaction to XML-RPC, and yet appear fairly comfortable with Linda.

Well, in that example, the application semantic is "ping" and the tuple is, as you say, (weblogname, weblogurl).  In a truly tuple space based or RESTful solution, the application semantic would be out()/POST, and the tuple/representation would be the same.

So you'd have a URI and you'd out() or POST the (weblogname, weblogurl) tuple too it.  The "ping" semantic would not be present on the network interface; it would be a side effect of the out()/POST action to that URI.

In a Linda space, an "out" would not equal a ping.  There would need to be another application which "in'ed" the data.  There would be an out of band agreeement between the source and the destination as to what tuples would represent a ping (as opposed to any other data inserted into the tupl-space).  This information would, by necessity, be contained within the tuple.

Agreed completely, but there are two different ways in which that information can be included within the tuples; via nouns or verbs.  The Weblog ping example uses verbs, while the Web uses nouns.  The advantage of the latter is that visibility is improved.

In the case of a weblog ping, there is only one documented service for that URI, so any other encoding of this information in the datastream is redundant.

In the case of a Linda tuple, if there is any other use of the this tuplespace, then there must be some other indicator in the tuple that conveys the information that "this is a ping".

Bottom line, from purely a REST perspective, XML-RPC is not inherently evil.  Nor is Linda a reinvention of the web.  There are profiles of each which conform to REST.  And there are usages of each, as there is with HTTP, in which knowledges of application state is implicit in client to server interactions.