Re: section 1, intro, for review

Chris Lilley wrote:
> 
> ...
> 
> Okay, but with a flourish I can produce the URI
> zip://atm.example.org/06902 or, worse, zip:06902 but just because
> these now have URIs does not lessen in any way their proprietary
> nature, and the second one is probably not dereferencable either.

Okay, but

 1. Why would anyone do such a thing? People know that non-HTTP URI
schemes have a massive barrier to acceptance.

 2. If you define your interface in terms zip: URIs, XML documents and a
REST-y zip: protocol, I can easily compete with you by defining an
alternate interface in terms of http: URIs, XML documents and the HTTP
protocol. You will be forced to support HTTP also just to compete.
Whereas, if you hide your data model behind a non-REST interface,
building an HTTP bridge to it could be a huge challenge.

3. Even a proprietary URI scheme is better than an arbitrary RPC
interface as long as it supports GET, because it is possible to add
dereferencing for a new URI scheme to (let's say) the whole JVM or all
.NET applications through well-documented component interfaces. So you
could get both an XSLT engine and a browser written for the JVM to have
access zip: data for the price of one component, not two. If these new
schemes actually arose as often in practice as they do in theory I could
imagine some slick APIs where an application would have a private cache
of handlers, and then fall back to the runtime library, which would fall
back to the operating system. So if you could find a handler for any of
Mozilla, or XPCOM or Linux you would be able to access zip: data. I'm
fairly confident that this stuff only works today for GET, not
PUT/POST/DELETE.

 Paul Prescod

Received on Monday, 18 March 2002 21:13:39 UTC