Share via

weblogs.asp.net and blogs.msdn.com changes

  • Article

After my last entry I got more than a few comments, I also posted an internal mail about it. After a few minutes I got an email from one of my managers abroad asking for me to explain why I felt it was wrong to cut the RSS feed and the Main feed. I can say that the higher ranks were listening all the time and really acted.

You can see the changes right now in two ways:

1. The RSS feed now gives the full content.

2. The Main Feed on the site has grown to 1250 characters.

Thanks for everyone who made their opinion heard to make this change.

Comments

  • Anonymous
    September 16, 2004
    I wonder why nobody comes up with incremental RSS?

    like sharpreader could post to
    rss.aspx?lastpost=20040916T1254 and it should still do the once per hour thing, [i think RSS bandit doesnt wait long enough]
  • Anonymous
    September 16, 2004
    I was thinking about this the other day. Most of the solutions I've seen suggested require one (or more) of the following:

    1) A whole separate feed for consumers that are aware of the new 'incremental' feature
    2) Some standardization of how the desired timestamp is transmitted from consumer to producer
    3) Some modification to the already haphazard (from what I've heard) RSS format standard
    4) Some agreement between consumer and producer as to what time it is (difficult considering how many computers and feeds have incorrect timezone information)

    It occurred to me that there's a way to do this which requires none of these things. The same feed can be provided to consumers regardless of whether they understand incrementalness or not, there's no need to standardize anything, and no modification to RSS is needed.

    It's a two-step process:
    1) RSS consumers should respect cookies - ie, store any Set-Cookie headers sent with the feed, and send those cookies back on the next request.
    2) RSS producers should send a timestamp (in whatever format or timezone they want) in a cookie, indicating the time that the request was made. If they receive that cookie with a request, they should only send entries made or modified since that timestamp.

    Notice the nice attributes of this process:

    1) Nobody tries to dictate the format of the cookie.
    2) Consumers that don't save and resend the cookie get the same behavior as today - no problem.
    3) Consumers designed to support cookies don't need any special case code to support producers that don't use this technique.
    4) It uses the existing HTTP standard rather than trying to define a new one. HTTP libraries generally already know how to handle cookies, meaning this should be easy for both producers and consumers to support.

    The biggest downside is that it doesn't help for RSS files that are statically generated. I don't think it's possible to do this while still meeting my original four constraints.
  • Anonymous
    June 08, 2009
    PingBack from http://quickdietsite.info/story.php?id=484