[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Atom Content Negotiation (follow-up)
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,
erik wilde | mailto:dret@xxxxxxxxxxxx - tel:+1-510-6432253 |
| UC Berkeley - School of Information (ISchool) |
| http://dret.net/netdret http://twitter.com/dret |