Re: PaceContentNegotiationSection

It seems to me that the purpose of an "introspection" document is to allow a 
first-time visitor to a domain to determine what compatible services are 
available.  The debate about the service document is concerned with being 
able to find collections automatically, so why is finding the service 
document a manual operation?

>
>Everything above is given in "help sections" of the related products.
>Why would it be any different with the Atom Protocol used within any
>other system?
>

Because I thought the Atom Protocol was meant to standardize interaction with 
weblogs and such, instead of saying that each weblog app can locate its 
introspection file wherever it wants requiring that an HTML page must first 
be dereferenced which links to it.

So yes, I thought it would be different than the mish-mash of current 
implementations.  There's also the issue of it being a per-user resource, so 
if the home page links to the negotiation point, then requests for the 
service document by logged-in users trigger content negotiation every time.

Under my setup, the service document is accessed once in a conneg scenario, 
after which the user has their own service document (userid.atomsrv) cached 
on their client, and when it needs refreshing it may just be requested, 
instead of being renegotiated.

-EJB

>-----Original Message-----
>From: Thomas Broyer [mailto:t.broyer-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx]
>Sent: Friday, August 18, 2006 11:39 AM
>To: 'Atom-Protocol'
>Subject: Re: PaceContentNegotiationSection
>
>
>2006/8/18, Eric J. Bowman:
>> Again, this is not my problem, it was not my idea to state that there could
>> be this "service document" without giving me any hint at all as to where it
>> should go, but did provide a MIME type.  So I assumed that was so that I
>> could negotiate for it at some other address-in-use.  I complained that the
>> spec was suggesting two distinct resources with the same URI by not
>> describing a standard address to find the service document.
>
>It is not suggesting anything along those lines. The spec says the
>service document has an IRI, nothing more, nothing less.
>
>If you want to use the Atom Protocol to edit your Google Calendar,
>you'll find the collection IRI in the calendar's options.
>If you want to use the Atom Protocol to edit your Blogger blog, you'll
>find the collection IRI in a <link rel="service.post"> in the HTML
>document at the root of your blog, or retrieve some kind of "service
>document" by requesting the feed at
>http://www.blogger.com/feeds/default/blogs using your user
>credentials.
>Yes, Google do not use the current draft's service document, but this
>is not really different.
>
>If you want to edit your WordPress blog, you'll find the admin section
>by adding "/admin/" at the end of your blog's URI.
>If you want to edit your MovableType blog, the "admin section" will
>depend on how you installed and configured the system, but will likely
>end with "/mt/mt.cgi".
>
>Everything above is given in "help sections" of the related products.
>Why would it be any different with the Atom Protocol used within any
>other system?
>
>-- 
>Thomas Broyer
>
>