Re: Atom Content Negotiation (follow-up)

[Erik Wilde <[e-mail]>]

hello james.

> I don't get why you rejected the "link content variants" solution. You
> don't necessarily have to include the HTML version inline - you could
> just have a very basic text summary.

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).

> And even the summary isn't strictly necessary. You don't seem to be
> particularly interested in producing a feed that would be useful to a
> typical feed reader, so you might as well go with the bare minimum
> necessary to make the feed valid.

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.

looking forward, i want to use feeds for pushing content, and in 
particular in frameworks supporting fat pings (such as PudSubHubbub), 
the effectiveness of pushing would be greatly diminished if for each 
pushed entry, the client would then need to GET the linked content 
variant. instead, it would be much better if different clients would be 
able to discover feed variants and then get the content pushed to them 
that they want.

these use cases may not be the ones you're interested in, but they do 
exist, and therefore i am wondering how to best address them.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[e-mail]  -  tel:[phone] |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |