[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-atompub-protocol-14.txt


On 3/17/07, Roy T. Fielding <fielding@xxxxxxxx> wrote:


It is only when we talk about specific applications of AtomPP,
such as an authoring interface to a corporate blog, that we can
say anything about the anticipated state change on the server.
SUCH INFORMATION DOES NOT NEED TO BE IN THE PROTOCOL SPECIFICATION.

Is that clear?  Maybe someone needs to write an application guide
for transparent authoring via Atom, and maybe that guide should be
very prescriptive in terms of what content needs to be preserved
on any given PUT in order to be acceptable by users who are
expecting transparent behavior.


+1

We are in the process of defining 4 different applications for AtomPP
and I suspect that a "general purpose" atom client will only work with
one of them (and that's if there is such a thing as a general purpose
atom client).

Here's a simple example where we are currently confused / struggling.
We are shortly going to ship a product that contains a Blogging
Component and a Bookmarking Component (ala delicious). They both
expose an AtomPP based API.

The blogging component expects posted atom entries to contain a
"content" element containing the blog post. The bookmarking component,
however, expects the "url to be bookmarked" to be contained in the
alternate "link" element within atom entries submitted to it.  In
short, they both expect completely different types of atom entries and
will reject entries that don't conform to their particular
application.

These are both completely valid AtomPP "applications", however at the
interop event I suspect that no atom client will be able to work with
our bookmarking component.

So where do we document the specific application behavior? and more
importantly how does a client discover this? I completely agree that
specific application behavior should not be in the protocol
specification, but should the spec describe the means for a client to
discover the "applications" the server is offering via AtomPP?

Rob

p.s.  We hope to have both of these components at the interop event
(pending legal approval)