RE: Binding

Yes, we're in agreement.  There is a certain amount of a priori 
information that is required to put the data accumulated through the 
coordination process into context.  Without a priori knowledge of 
fibonacci sequences, either example (a page full of numbers or a sequence 
of GETS that return each subsequent number) is meaningless. 

The paradox in this is that Mark is both right and wrong.  Where Mark 
seems to go most astray (IMHO) is that you simply cannot come up with a 
single architectural design pattern that describes the ideal Internet 
application. REST is a useful abstraction but it's not the only 
abstraction.

- 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



"Abbie Barbir" <abbieb@nortelnetworks.com>
01/07/2003 09:45 AM

To
James M Snell/Fresno/IBM@IBMUS
cc
Walden Mathews <waldenm@optonline.net>, www-ws-arch@w3.org
bcc

Subject
RE: Binding





well, 
from your example, is the inceremental fibonacci needed for the overall 
solution, or each number is needed for a solution or a particular.

the point is is that u still need to know the context (whether 
inceremental or not). 

I guess, we are in agreement (??). 

abbie 

> -----Original Message----- 
> From: James M Snell [mailto:jasnell@us.ibm.com]  
> Sent: Tuesday, January 07, 2003 12:03 PM 
> To: Barbir, Abbie [CAR:1A00:EXCH] 
> Cc: Walden Mathews; www-ws-arch@w3.org 
> Subject: RE: Binding 
>  
>  
> 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 13:03:08 UTC