Re: timeless atom

["Thomas Broyer" <t.broyer@xxxxxxxxx>]

Hi Erik,

2007/12/8, Erik Wilde:
>
> > The specs are separate for a reason. Why conflate them?
>
> i did not suggest to conflate them, i was simply pointing out that time
> as the primary sort key has been built into both specs.

Time is the sort key of Atompub collection feeds. Each Atom entry must
be timestamped but it does not have to be the sort key of a feed
(except when it is an Atompub collection feed, but then the timestamp
is not the same: updated vs. edited).

> >     4.1.1. The "atom:feed" Element
> >        This specification assigns no significance to the order
> >        of atom:entry elements within the feed.>
> > You can order *a* feed any which way you want. Not a *collection*
> > feed, but not all feeds are collection feeds.
>
> yes, but that does not really solve the question of how i can specify
> the sort order when requesting a feed.

Neither Atompub or Atom deal with querying.
Atom is "just" a format (as Aristotle pointed out, Atom does not
mandate a sort order for entries within a feed).
Atompub only deals with listing members of a collection, by mean of a
GET request to the collection feed (remember: appending a query-string
makes a distinct URI). Atompub does not preclude using other
mechanisms to list or query the collection members, nor does it
preclude returning a 405 status in response of a GET to the collecton
feed if you don't want to provide the sort-by-atom:edited "entry
point".

> >> 1. there may be some other implicit primary sort key, which
> >>    is used for publishing the feed. this would conflict with
> >>    AtomPub's SHOULD, but that is allowed.
> > The collection feed must be the way it is specified in RFC 5023
> > if it is to be useful to editing clients. Just because you are
> > allowed to break a SHOULD doesn't mean it's a good idea. Please
> > read RFC 2119 – "SHOULD" doesn't mean "might we suggest that
> > perhaps you entertain the idea that maybe you could."
>
> you are right with the SHOULD remark, but not with the rest. if my
> entries don't have an implicit time order, then it just is not very
> useful to assume that they have one. i can edit things just fine that i
> retrieve by some query and then POST to the atompub server.

The main use-case of Atompub is to be able to use offline clients,
hence the collection feed sorted by atom:edited to help synchronize
local caches. But if your use of Atompub does not fit in this use-case
(and you don't want "generic Atompub clients" to be able to interact
with your server, i.e. you have control on both the server and client
ends), then you can just violate the SHOULD without a fear for
interoperability.

> so what you say is atompub is only meant for time-ordered feeds that are
> meant to be consumed by time-oriented feed readers or consumers? that
> would kind of answer my big question, but in a disappointing way. what
> that would is that i would have to build my own atompub (since i want to
> be able to interact with collections in the way atompub does it), only
> with the slight variation that "my" atompub does not say one SHOULD
> produce time-ordered feeds? that looks kind of weird to me, and it
> certainly is disappointing, but i would like to get more opinions on
> this. should there be this "untimed atompub"?

As I said above, you're free to return a 405 in response to a GET if
you provide another mean of listing collection members. Clients would
then have to be aware of your extension to the protocol.

> >> but AtomPub tells us that listing collection members always
> >> uses GET, which means we cannot POST the image.
> > Yes, if you POST to the collection URI, the assumption is that
> > you want to store the image as a media resource in the
> > collection.
>
> so what about a GET with a body? would be atompub compliant, or at least
> it would not violate any specific text in the spec, i guess.

I wouldn't recommend it (wouldn't there be risks that intermediaries
remove the reqest body? or maybe you're in control of the whole
environment, including the network), but I think it would work.
I'd rather use another URI.

Note that if you don't want to be able to create a member when sending
an image to the collection, you could accept POST requests with an
image body to the collection feed as a mean of querying the collection
(provided you don't list image/* in your service document's
app:accept). It could work, though I wouldn't recommend it either.

> > But there's nothing stopping you from minting another URI for
> > querying the collection and advertising it in the collection with
> > `<link rel="image-query" href="..."/>` or something like that.
> > Clients which understand your query-by-example-image protocol
> > will know to look for that link.
>
> yes, but that simply means you are pointing to the "other atompub" you
> are proposing. i am not yet willing to go that way.

Atompub doesn't deal with querying, so whatever solution you choose,
you're extending the "core" protocol, and this is not at all a Bad
Thing.

-- 
Thomas Broyer