RE: Atom Content Negotiation (follow-up)

[James Holderness <[e-mail]>]

> i don't reject it, but it makes it necessary to issue additional GET 
> requests for each single entry. if you know that all you ever want are 
> the linked alternate variants, then it would be much more effective to 
> simply GET those in a feed (if there was one and you could find it).

With HTTP pipelining those multiple GETs shouldn't have that much of a negative impact, although I'll admit that in practice pipelining does have potential problems.

But even without pipelining, after the first feed retrieval, I would still expect those multiple GETs to be more effecient on subsequent updates. Two small GETs to retrieve one new feed entry would seem more efficient than one giant GET of a 20 entry feed when you only want the latest entry (unless you're also supporting RFC3229+feed?)

I guess this does depend to a some extent on the nature of your data, the frequency of updates, and the kind of clients you expect to have. Either way, though, I think you may be optimizing prematurely.

> i am interested in producing feeds that are useful to feed-consuming 
> clients. human-oriented feed clients prefer HTML, whereas other types of 
> clients might prefer XML or RDF or something else.

I still think you are going about it the wrong way. If the content-type for Atom doesn't sufficiently distinguish between the types of feed you want to serve for HTTP content negotiation to work, it seems to me you should be looking at ways to extend the content-type (like the type parameter that was proposed to distinguish between Atom entry documents and Atom feed documents). Inventing a new form of content negotiation that requires parsing links from the top of an Atom feed is just twisted.

But the real problem may just be an inappropriate use of Atom as a general purpose container format. If you have a client that prefers content as RDF, why not give them a true RDF feed? Why RDF embedded in Atom? That kind of misses the point of RDF. Even worse, if a client prefers JSON, do you really think it makes sense to serve them that JSON as base-64 encoded blobs inside an XML container? I can assure you that nobody is going to thank you for that option.

If you served RDF clients a real RDF feed, and JSON clients a real JSON format, then you could be using standard HTTP content negotiation - at least for most cases. If you wanted to provide an "HTML friendly" feed that was separate from the one with raw XML embedded, you'd still need a way to differentiate between the two, but at that point I would think it not worth the complication. I'd just make your feed content the raw XML, include a short summary, and then an alternate link to a more detailed HTML page if really necessary.