On 6 Jul 2006, at 18:54, James M Snell wrote:
Henry,
I very much do NOT want the Introspection Wars to start over again,
however, if folks can behave, I think there are some good things we
can
do at this point.
Yes. I don't want introspection wars to start again either. I hope we
have gone beyond that now. If I made a weird noise yesterday it was
the shout of someone removing a Band-Aid from a healed scar. One
still shouts in expectancy of pain, often to the great amusement of
bystanders :-)
Over the past nine months I've written five Atom server
implementations
and am currently working with Elias on a sixth. In every case, the
introspection document played a non-critical role as far as the core
behavior of the protocol is concerned. They have, however, proved
useful for bootstrap when augmented with information about what media
types, features, extensions, behaviors, etc are supported by an
implementation, or when trying to figure out the complete set of
collections that are available to a client.
To be completely honest, at this point, I would very much prefer that
the service document format be dropped from the spec and that the
app:collection element be redefined as an extension to atom:feed,
atom:source and atom:entry. This would allow feeds/entries to
claim an
association with an APP endpoint and gives a place to hang APP
specific
extension metadata. A service document format that incorporates
app:collection could be reasonably defined by a separate
specification.
I am very interested to understand what the minimal information
needed is. Is the app:accept element not all that is needed as
proposed in this Pace? Perhaps one need an edit link on a non
writeable feed to point people to the edit location?
I don't believe that the service document work would be lost by
removing it from the pace. It could be re-used in another spec to
give information about rights and properties of feeds. Writing good
xml formats though is so hard (I remember vividly the work that went
into the atom spec) that it seems best to leave this piece out of the
puzzle for the moment. If one can then use the Atom APP to post such
a document, like any other, it would seem that we would also have a
very good and clear separation of concerns. One could always create a
feed:introspection or feed:admin link to point to such a document.
My concern is at present: what is really necessary to get APP to
work. What will survive the test of time.
That said, however, I'm not going to argue the point because the stuff
that's currently in the spec is very simple and low cost to implement,
serves a useful purpose, and does not get in the way of
implementing the
core protocol operations.
Well perhaps now that I have pulled of the band-aid and survived,
others will find it is not such a bad thing to do anyway :-)
Henry
- James
Henry Story wrote:
This pace is a simplification pace and is under development.
Feedback on
the general idea would be appreciated, as well as on positive
improovements to it.
Henry
http://www.intertwingly.net/wiki/pie/PaceNoServiceDocument
#pragma section-numbers off
== Abstract ==
Remove the Service Document from the Protocol Spec.
== Status ==
under development
== Rationale ==
The Service document is not well enough defined, and does not contain
any information that is really needed for the protocol.
It can be removed safely from the protocol document.
== Proposal ==
Replace 5.1
{{{
5.1 Retrieving an Introspection Document
Client Server
| |
| 1.) GET to URI of Introspection Document |
|------------------------------------------>|
| |
| 2.) Introspection Document |
|<------------------------------------------|
| |
1. The client sends a GET request to the URI of the Introspection
Document.
2. The server responds with the document enumerating the IRIs
of a
set of Collections and the capabilities of those Collections
supported by the server. The content of this document can
vary
based on aspects of the client request, including, but not
limited to, authentication credentials.
}}}
to
{{{
5.1 Retrieving a Collection
Client Server
| |
| 1.) GET to URI of Collection |
|------------------------------------------>|
| |
| 2.) Feed Document |
|<------------------------------------------|
| |
1. The client sends a GET request to the Collection URI
2. The server responds with an atom Feed document . If this
document
contains an
app:accept element, this specifies what type of mime types
can be
POSTED to this uri.
}}} [snip]
