Re: PaceNoServiceDocument - Re: Some feedback on current APP issues

On Fri, 18 Aug 2006 18:46:40 +0200, Tim Bray 
<Tim.Bray-UdXhSnd/wVw@xxxxxxxxxxxxxxxx> wrote:

> Speaking as one who's currently working on an APP client, I find the  
> service doc to be easy to understand, and a natural tool for  
> bootstrapping client operations.  I can't imagine why we'd want to do  
> away with it

Well, I just feel that in some cases the current format isn't sufficient  
(in full-scale CMS systems for example) and for other uses, it's really  
superfluous. For blogs with more than one feed, it serves a purpose, but  
these other use cases makes me think that the service document should be  
external to APP and be in whatever format (though preferably a  
standardized one) the publisher whants.

What the APP needs is an entry point. Since introspection of feeds is  
already standardized, why can't we use that mechanism, starting with the  
URI of the front web page of the author?

  1. The APP client asks for the service entry point.
  2. The user enters the web address http://example.com/
  3. The APP client introspects and finds the URI to the feed which is
     http://example.com/feed/
  4. APP can start working with the feed, looking for service URIs to
     operate on.

If the client is a web browser, it would probably look like this:

  1. The browser is instructed by the user to visit
     http://example.com/.
  2. The browser displays a "service icon" somewhere to signify that
     this web page can be edited with APP.
  3. The user clicks the icon, authenticates and gets going.
  4. APP can start working with the feed, looking for service URIs to
     operate on.

I'd prefer this instead of the service document and rather have all  
service endpoints inside the feed if we need to.

--
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»