RE: Binding

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 <mailto:abbieb@nortelnetworks.com>  
To: James M Snell <mailto:jasnell@us.ibm.com>  ; www-ws-arch@w3.org
<mailto: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 <mailto:jasnell@us.ibm.com>
] 
> Sent: Monday, January 06, 2003 5:29 PM 
> To: www-ws-arch@w3.org <mailto:www-ws-arch@w3.org>  
> Subject: Re: Binding 
> 
> 
> 
> Coordination without Context is useless. 
> 
> http://www.snellspace.com/blog/2j43h5kmne54324u23kjl234sdf878.html
<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
<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 11:20:29 UTC