« If you must poll, at least poll well... | Main | Implementations of RFC3229 with "feed" »

September 13, 2004

Comments

bryan

Why not use Vary to indicate the additional headers which provide a complete caching context?

With respect to Range, I've just written up the use of this HTTP header for addressing and direct manipulation of subresources using the XPointer Framework for an extensible addressing platform. Since the conference (Extreme Markup 2004) has not yet (!?!) published the paper online, I'll send you a copy in email.

By the way, I did a similar thing with REST-ful queues where the parameters were in the query string. Worked fine. I used it to back an RSS service so that you could get slices of the RSS feed based on any indexed properties from the queue entries. I've been meaning to revisit this using the Range header.

-bryan

Bob Wyman

James Robinson reports that he has implemented diffe based RFC3229 support for Wordpress. Hopefully, he'll support the "feed" IM method as well... see:
http://www.robinsonhouse.com/2004/09/14/rss-and-delta-encoding/

bob wyman

Paul Burdick

Bob - I just implemented RFC3229 for ExpressionEngine this morning allowing both diffe and feed, and I am wondering if the Apache support is really the only thing holding this back now?

Laird Popkin

People here should be aware that ICE (Information & Content Exchange) is an XML-based syndication standard that has been providing incremental updates since 1998 or so. There are some real limitations of presenting "deltas" at the HTTP layer rather than the application layer, because (IMO) the semantics are more appropriate. That is, HTTP offsets are really intended to be byte offsets into the content of the resource being delivered via HTTP, while at the application (ICE) level it makes sense to have instructions such as "here's a new version of story 123" or "delete story 456, and add story 789".

For info on ICE2, see http://www.icestandard.org.

Winter

Is there anyway to indicate that an entry has been deleted? Would there need to be?

Alan Williamson

But isn't the problem of bandwidth not already been solved in HTTP? There are many headers in the HTTP specification that helps with this. Speaking as a blogging hoster who supplies GB's of RSS feeds each month, it amazes me how many hosts/feedreaders do not even attempt to present Last-Modified, or ETAG data to determine if they have the latest information already. If they were to do this at least, then the amount of bandwidth consumed would drop like a stone overnight.

So while i applaud this effort, i can't see it solving the problem. It is just another layer of administration that feedreaders will not implement. Its laziness and inability to appreciate that HTTP has already answered many of the problems facing our RSS world today. Previously it was easy; it was largely down to the browser engineers; and since there was a finite amount of them, they all adhered to the standard. However, since there is so many different RSS readers out there, including all the RSS Developers APIs for reading and parsing feeds, no one is bothering to think about the poor HTTP protocol wire its eventually going out on. So when a developer creates his new RSS reader, its not his bandwidth they are consuming, but instead the countless clients of their creation. Why should he be worried about the bandwidth?

Therefore, instead of actually using the tools and headers available, we find ourselves having to create more standards to solve the problem. I don't think its the way to go.

Bob Wyman

Alan, certainly we would all be better off if clients actually implemented conditional GETs with "if-modified-since" or Etags. However, even if they did, we would still be wasting bandwidth in the case where some of a feed has changed but not all of it. In terms of priority, supporting conditional GETs is certainly higher then RFC3229+feed, however, once you've provided support for conditional GETs, the incremental effort to support RFC3229+feed is trivial while the benefits are great. As I've documented elsewhere on this blog, we saw a massive drop in bandwidth needs the moment we implemented RFC3229+feed ourselves. This is because many of the more popular feed readers *have* built in support for RFC3229+feed. If you were to implement this at blog-city, I think you would also find massive improvements -- even though there are still many clients that don't support it.

bob wyman

Talea Joy

Great site, well done. I enjoy beeing here and i´ll come back soon. You do a great job. Many greetings.

Frauke

Great site, well done. I enjoy beeing here and i´ll come back soon. You do a great job. Many greetings.

bandwidth

great article adn well written

Funny Videos

You are right. I lose lot of bandwidth to the feeds

Andres

Hi,

Can I use delta-encoding in cache-nocache multipart messages?

How to apply delta-encoding inside an html page?

Thanks a lot

Fletcher Todd

This is a good intermediate step on the way to the push-based solutions.This post is intended to provide additional detail on what I'm proposing.

The comments to this entry are closed.