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

Re: timeless atom


hello aristoteles.
thanks for your words of wisdom ;-) (sorry, you must hear this lame joke all the time...) 


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. 


    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. 


Why do you want to avoid timestamping entries? Even if the data
itself is not chronological in any sense, there is certainly a
time at which a collection member was created, last updated
significantly, and last edited. There are always sensible time-
stamps to associate with collection members, so the requirement
to have them does not preclude the use of Atom for anything.
i don't want to avoid timestamping. i just don't want to treat the timestamp as something special, in fact, in the scenarios i am thinking about it is a pretty minor attribute. but i don't mind being forced to have it everywhere. 


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. 


How do you propose that Atompub clients synch their local cache
to the collection efficiently? They need to know which entries
have been edited since they last saw the collection. What sort
key would you propose for the collection that would allow them to
do this efficiently? There aren’t all that many candidates if you
look at it this way, are there? :-)
i don't see such an emphasis on caching as you imply. for detecting cached entries, ids work fine, and if there is no implicit order, then caching will be less efficient, but for atom feeds not using time as the primary key, caching based on timestamps would not a good idea anyway. 


But this applies only to collection feeds. And there’s nothing
that prevents you from producing multiple feeds from a single
collection. In fact, experience is establishing it as something
of an antipattern to use the collection feed as the public feed
precisely because the collection feed needs to serve a very
specific set of needs whereas publically available feeds are
usually supposed to serve any number of other desires. (Even when
a public feed is time-ordered, people usually want it ordered by
atom:updated rather than app:edited.)
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 far as you want. Look at OpenSearch.
they don't even use atompub, and they have their own vocabulary for what already has been proposed by sle or atom ranking extensions. is that good? i think atompub's basic ideas are very good and very useful, all i am looking for is a the right way how to deal with the built-in time bias. i think reuse is good, most of the time, and want to do it. 


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. 


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. 


You came with some misconceptions about how one would try to do
this sort of thing with Atom and Atompub; but the facilities to
do it properly are all there.
where are they? in http? sure, but atompub is a nicely designed and promising restful protocol, so i'd rather use that one than inventing another one. 


To some extent it *is* already being done: aside from OpenSearch,
which I mentioned above, I think GData has some non-trivial
querying facilities too.
so they use opensearch as their atom rankinf extensions. they use atompub and support queries. queries are GET only. interesting. i have to look a bit closer as to what they say about ordering of feeds according to the timestamp. thanks for the pointer! 

cheers,

dret.