- From: James M Snell <jasnell@us.ibm.com>
- Date: Tue, 7 Jan 2003 09:03:16 -0800
- To: "Abbie Barbir" <abbieb@nortelnetworks.com>
- Cc: Walden Mathews <waldenm@optonline.net>, www-ws-arch@w3.org
Simple example of a process that yields context incrementally: a page that gives you the next number in a fibonacci sequence each time you load it. Each step in the process (each GET) yields a little more information which builds context. In reality, none of this stuff can be cleanly separated. All we can do is attempt to make somewhat useful abstractions of reality. Disagreement is endemic in the process. So is getting it wrong and having to try it again. - James Snell IBM Emerging Technologies jasnell@us.ibm.com (559) 587-1233 (office) (700) 544-9035 (t/l) Programming Web Services With SOAP O'Reilly & Associates, ISBN 0596000952 Have I not commanded you? Be strong and courageous. Do not be terrified, do not be discouraged, for the Lord your God will be with you whereever you go. - Joshua 1:9 www-ws-arch-request@w3.org wrote on 01/07/2003 08:19:51 AM: > Walden, > > It would help if u give an example of what do u mean by > "a coordination process yields context incrementally" ? > > PS: Seperation may not be 100% clean, but it does not hurt to > attempt it, knowing that it will not be perfected either. > > thanks > abbie > > -----Original Message----- > From: Walden Mathews [mailto:waldenm@optonline.net] > Sent: Tuesday, January 07, 2003 11:14 AM > To: Barbir, Abbie [CAR:1A00:EXCH]; James M Snell; www-ws-arch@w3.org > Subject: Re: Binding > > Okay, but what about cases in which a coordination process yields > context incrementally? Are you sure coordination and context can > really be separated out so cleanly? I would call the example given a > case of "degenerate coordination" at best, and not generally what's > meant by coordination in this thread. But I could be reading in meaning > that's not intended. > > Walden > > > ----- Original Message ----- > From: Abbie Barbir > To: James M Snell ; www-ws-arch@w3.org > Sent: Tuesday, January 07, 2003 10:17 AM > Subject: RE: Binding > > James, > > thanks, > > it is about time this point is made by example. > > abbie > > > -----Original Message----- > > From: James M Snell [mailto:jasnell@us.ibm.com] > > Sent: Monday, January 06, 2003 5:29 PM > > To: www-ws-arch@w3.org > > Subject: Re: Binding > > > > > > > > Coordination without Context is useless. > > > > http://www.snellspace.com/blog/2j43h5kmne54324u23kjl234sdf878.html > > > > - James Snell > > IBM Emerging Technologies > > jasnell@us.ibm.com > > (559) 587-1233 (office) > > (700) 544-9035 (t/l) > > Programming Web Services With SOAP > > O'Reilly & Associates, ISBN 0596000952 > > > > Have I not commanded you? Be strong and courageous. > > Do not be terrified, do not be discouraged, for the Lord your > > God will be with you whereever you go. - Joshua 1:9 > > > > > > > > Miles Sabin <miles@milessabin.com> > > Sent by: www-ws-arch-request@w3.org > > 01/06/2003 01:54 PM > > > > To > > www-ws-arch@w3.org > > cc > > > > bcc > > > > Subject > > Re: Binding > > > > > > > > > > Mark Baker wrote, > > > On Mon, Jan 06, 2003 at 04:54:21PM +0000, Miles Sabin wrote: > > > > And the RESTless version could work just as well if we > > substituted > > > > "9ajp23q9rj89aweruwer" for "getLastSharePriceOfIBM". What allows > > > > this, in *both* cases is the _prior_ coordination between > > the client > > > > which has, > > > > > > Wrong. > > > > > > I think it's funny (in an unfortunate way) that this benefit is so > > > easily taken for granted. It's called a *coordination* > > language for a > > > reason, ya know. 8-/ > > > > > > http://www.markbaker.ca/9ajp23q9rj89aweruwer > > > > > > Quick, before you type that into a browser window, tell me > > everything > > > you and your browser know about it and what I'm trying to > > communicate > > > to you by putting it in this email message. > > > > Well now ... you're giving David all the ammunition he needs > > for his part of the argument. > > > > I know a fair bit about that URI a priori. I'm reasonably > > confident that there's something on the end of it. Also that > > any representation I get back will probably have a text/html > > MIME type. It's textual content will be in English, and > > relate to this thread in some way or another. Either that or > > it's a rude message ;-) > > > > I have that confidence because it's not _just_ a random > > string of characters. It's a URI posted in a mail to this > > list by a person, with a purpose, for human consumption. It > > has a context, a context which is shared by its publisher > > (you) and its consumers (the rest of us). > > > > I also have a reason for _wanting_ to see what's on the end > > of it: I'm just intrigued to see what's there. That's why > > I'll follow the link when I've sent this mail. > > > > But what if the consumer isn't a person? In general a machine > > won't know anything about that URI, it can't even guess. It > > won't autonomously follow it any more than it would follow > > any other link composed of a random string of characters. > > Unless, that is, it's a spider, in which case it'll blindly > > follow any link it's given ... but this is a list for Web > > _Services_ Architecture, not Web _Spider_ Architecture, and > > presumably we're all interested in getting machines to > > something a little more sophisticated than wandering blindly. > > > > If we want to do that, then we have to provide the machines > > with something analogous to the shared context that makes > > link following make sense in the human case. Machines being > > the dumb lumps of tin they are, that has to be a priori > > shared knowledge and semantics encoded some how or other. > > > > The SOAP/WSDL way of doing that is to encode knowledge in the > > communicating endpoints. The encoding is mostly ... code: and > > the SOAP/WSDL community has given developers a programming > > model, idioms and toolkits to help do the job of writing it. > > > > Another way of doing it might be to encode a significant > > portion of that knowledge in the structure of the network > > that the machines are traversing when they follow links. In a > > way, that's putting spiders to work by designing the network > > they wander over in such a way that their wandering produces > > a useful result. That this can be done is an insight from the > > mobile calculii people, and, IMO, it's the echoes of this in > > REST which makes REST interesting. > > > > But note ... even if the machines are dumber in this case, > > the network has to be smarter. Qualitatively speaking, the > > same work that goes into the design and implementation of > > RPC-style clients and servers would have to go into the > > design and implementation of a REST-style network. And it's > > harder work, because the programming model and idioms are unfamiliar. > > > > All that work has to be done up front just as in the > > SOAP/WSDL case, it doesn't come for free, and it isn't all > > there in RFCs 2396 and 2616 just waiting to be found. > > > > Cheers, > > > > > > Miles > > > > > >
Received on Tuesday, 7 January 2003 12:04:06 UTC