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

Asbjørn Ulsberg wrote:

> 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)


agreed and this is why we started Neutron some time ago, whereas Atom's 
original purpose was/is on blog-related software and hence it might make
sense to focuse on that

> 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,


I guess you mean

<link rel="alternate" type="application/atom+xml" title="Hello World" 
href="http://foo.bar/atom.xml"/>


right?

> 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.


this is how Ulysses does it

>   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.
If a feed is able to provide all information you need then fine, 
otherwise not.
I am still not familiar enough with the feed schema to make a real statement
on this.

One might just have to ask is the service/introspection document 
duplicating functionality of the feed or is it actual enhancing it in a 
useful way which wouldn't make sense to pack into a feed?

Michi


--
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner-m0ku3nyLTiYAvxtiuMwx3w@xxxxxxxxxxxxxxxx                        
michi-1oDqGaOF3Lkdnm+yROfE0A@xxxxxxxxxxxxxxxx
+41 44 272 91 61