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:[email protected] - tel:+1-510-6432253 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret |
