- From: Mark Baker <distobj@acm.org>
- Date: Wed, 17 Sep 2003 23:01:52 -0400
- To: Sergey Beryozkin <sberyozkin@zandar.com>
- Cc: www-archive@w3.org
On Tue, Sep 16, 2003 at 05:18:36PM -0400, Sergey Beryozkin wrote: > Hi Mark, > > You said in an earlier mail : > > Just that if it's not late bound, then client software needs upgrading > whenever new services are introduced. The opposite isn't true, however; > just because you are late bound, it doesn't mean you don't need client > upgrades to access new services. Consider an FTP client that supports > ftp URIs; when a new scheme is introduced, it needs upgrading to be able > to use it. It's really the combination of the uniform interface and > late-binding which is why the Web is so powerful; HTTP clients can > interact with *ANY* URI (perhaps with a proxy), because HTTP semantics > are uniform to *ALL* URI. > > Thanks for the explanation. I think I can see now how late-binding helps > HTTP clients, especially after seeing what a proxy can do. > This is how I see what a late-binding can do for a client : > For example, if a document of known mime-type is fetched for the purposes of > presentation, then it doesn't matter which scheme, http:// or custom://, was > used, Well, it matters for other reasons; not everybody might be using a proxy that knows the URI scheme.. which is why "http" makes such a fine default. > and yes, a presentation software (a browser in a simple case) doesn't > need to get upgraded. But if a document is of unknown mime type, then a > presentation software will have to be upgraded. Yes. > In other words, with late-binding, it's a layer which communicates with a > service(s) doesn't need to get upgraded, while an application layer may or > may not need to get updated. Right, modulo that it's sometimes called the application layer itself. There's no upper layer, just data flowing within that application layer. > The same probably applies to a RESTful (SOAP or XML) client which enables a > machine to machine communication. For example, if a new service is > available, then as far as a SOAP client stack (which wraps/unwraps XML doc > in/out of envelope, etc, sends and receives it) is concerned it doesn't need > to get changed. An application layer may not need to change as well, > provided the data returned is of known format or if those data can be > transformed into a known format by some generic pre-processing filter. > Otherwise, to avail of a new service's data, the application layer will have > to get changed as well. There's another option; the data format is generic enough to be able to communicate the information within other non-generic formats. i.e. RDF. See; http://www.markbaker.ca/2002/09/Blog/2002/11/17#2002-11-rdf > So, late-binding does indeed reduce integration costs for a client in that a > layer talking to (URI-)identified resources through a uniform interface > doesn't need to get changed. This is of critical importance to the Web in > general. Yep. > It seems that it would also be beneficial for a SOAP client as well, though > it's probably of less critical importance than it's for a general HTTP > client. > > Do you agree ? Well, up to that last part I did. I would say that it's of critical importance to any client using a service over the Internet, primarily due to reasons of visibility (I assume you've read Roy's dissertation). Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Wednesday, 17 September 2003 22:59:41 UTC