So, why is the so-called Semantic Web (caps absolutely Required) doomed to fail? While there might be lots of technical reasons, all you really need to know is that one of the core specs for the Semantic Web has the acronym of GRDDL. I'm sure they want me to pronounce that "griddle", but I can't help but pronounce it "girdle". What's even worse is what is stands for: Gleaning Resource Descriptions from Dialects of Languages. Gleaning? Really ... you're going with gleaning? I can understand picking lame-ass words to fit a bitchin' acronym, but you chose gleaning so you could nail down the girdle acronym? I really don't need to know any more about these people.

This has become a useful filtering mechanism, actually. I get contacted by lots of different companies about all sorts of things (note to tech recruiters: I will never ever answer my phone, so stop calling). Now, when I check the company's web page, if the words "Semantic Web" show up I know I can ignore them, as they will be neither competitive nor complementary to anything I'm interested in doing.

One of the key parts of FeedBurner's stats processing is trying to determine if a request for a feed represents a casual, drive-by browse or an intentioned subscriber. It has gotten a little bit more complicated lately as some clients serve double-duty. I wanted to share with you how we handle the requests from the two most popular browsers, Firefox and Internet Explorer 7.

Firefox

The Firefox browser can also be used as a feed-reading client with the Live Bookmarks feature. So, the key for FeedBurner is to determine if a request for a feed is coming from Live Bookmarks (where we can count it as a subscriber) or from a visitor that just happened to click on the feed chicklet (where we just report it as a browser hit). Up until Firefox version 2.0.0.1, we really have to guess, since the requests for the most part look identical: they both have a User-Agent that looks like Mozilla/.*Firefox/.*. So, what we do is that we look at a couple of other headers: X-Moz and Referer. So the logic tree looks like this:

If version < 2.0.0.1 and (X-Moz: prefetch or Referer is not empty), then it's a browser.

Otherwise, it's a Live Bookmarks request.

That's not ideal, because if someone just types in the feed URL in the location bar or launches the feed URL from a different app, we'll count it as a Live Bookmarks hit because the Referer will be empty. But we have nothing else to hang onto.

Firefox 2.0.0.1 has a wonderful new addition that makes this tracking much more accurate. Now, if the request is coming from Live Bookmarks, there will be an X-Moz: livebookmarks header. We can detect that and we don't have to do the referrer guessing game.

If version >= 2.0.0.1 and X-Moz: livebookmarks, then it's a Live Bookmarks request.

Otherwise, it's a browser request.

Internet Explorer 7

The latest version of Internet Explorer adds feed reading capabilities by leveraging the Windows RSS Platform. So, on the surface, things seem really straight-forward, since the Windows RSS Platform has its own User-Agent that's distinct from the IE7 User-Agent.

If User-Agent matches Windows[- ]RSS[- ]Platform/\S+ .*, then it's a "Windows RSS Platform" subscription.

At this point, however, things get complicated. Outlook 2007 has a cool feed reading capability. Unfortunately, the Microsoft Office team didn't get the memo and identifies itself the same as IE7 instead of leveraging the Windows RSS Platform, which would have made much more sense. So how do we distinguish between IE7 browser hits and Outlook 2007 subscriptions? We use the old referrer trick: if there's no referrer, assume it came from the automated poller fueling Outlook.

If User-Agent matches Mozilla/4\.0 \(compatible; MSIE 7.* and Referer is empty, then it's an Outlook 2007 subscription.

But wait ... there's more! It turns out that some Microsoft Vista Gadgets also identify themselves as IE7, and we think it's more appropriate to treat those requests as subscriptions rather than browser hits. Fortunately, there's a hook: we can look at the Referer, and if it starts with x-gadget:///, then the request is coming from a Gadget.

If User-Agent matches Mozilla/4\.0 \(compatible; MSIE 7.* and Referer starts with x-gadget:///, then it's a Vista Gadget subscription.

Finally, if none of the other rules match, we treat it as an IE7 browser hit.

So, those are the kinds of decisions that we make when evaluating each of the over 300 million feed requests we get each day. We're constantly reviewing the list of User-Agents we get in those requests in an effort to make these stats as accurate they can be. What really makes our lives easier is when we can definitively discern through request headers if the request is for an intentioned subscription vs. "other". With developments like a distinct User-Agent header for the Windows RSS Platform and the new X-Moz header, we're getting closer!

I recently checked my email archive to find out when, exactly, we launched the "pre-alpha" of FeedBurner. Turns out it was February 25, 2004 ... three years ago today. Happy birthday, FeedBurner!

Here was the original email that we sent out to friends and family on that day. I'm amazed with how we've pretty much stayed on target with our original vision.

Hi there,

We are very excited to announce a pre-alpha release of our new service, FeedBurner.com ( http://www.feedburner.com ). FeedBurner is an RSS/Atom post-processing service that enables publishers of syndicated content to enhance their feeds in a variety of interesting and powerful ways. By "pre-alpha", we mean that the software still contains a number of bugs, and while we wouldn't release something that was "unstable", we also wouldn't go throwing around the term "high availability" just yet either.

Our pre-alpha release contains a small subset of the services we will be rolling out over the coming weeks. Look for additional services like authenticated feeds (enabling premium content to be syndicated), "future-proofing" to eliminate the market's current debate over feed formats, and even content namespace enhancements to facilitate the broad syndication and feed-splicing of rich content types (eg, think syndicated music meta-data and associated news and purchase information).

As syndication and non-browser content aggregation/display become rapidly more popular, we believe our "syndication clearinghouse" model will provide a large collection of publishers with an enourmous [sic] amount of leverage in the market. For example, today even the most popular bloggers have little to no control over how frequently their content is polled, what newsreaders do with their content layout/style, or how many advertisements are layered into the display at the fringes of syndication. Nor are they afforded any revenue opportunities for their syndicated content. By channeling large numbers of publishers through our post-processing facility, we can begin to help these publishers effect changes to their benefit in a number of interesting ways ( poorly coded newsreaders that excessively drain bandwidth can be shutout, significant opportunities to provide revenue channels to the individual publisher emerge, and much much more).

If you'd like to stay up to speed on the service and the company, we are going to maintain a weblog at http://www.burningdoor.com/feedburner that tracks the progress of the company and service, and we'll also use this space to discuss publisher services and business issues.

best,

Dick Costolo
CEO
Burning Door Syndication Services, Inc.
http://www.feedburner.com

First off, let me just say that I think Yahoo! Pipes is very cool and that it has the potential to be an important building block for the next phase of the web (see "A More Personalized Internet?" for an overview). It's the logical next step for this ecosystem that is made possible because of the standard content interchange format called a "feed". Feeds first allowed there to be a loose coupling between content publishers and content consumers and let each evolve separately. Then, FeedBurner came around and showed that this loose coupling also enabled value-add middleware that respected and in some cases even strengthened the "content contract" between the producers and clients. Pipes is a logical next step which does a very cool thing: it allows external parties to construct content workflows and, most importantly, gives them a sharable URL. FeedBurner and Pipes actually complement each other very well, and I've been having a lot of fun over the past week demonstrating that.

There are some very interesting directions that Pipes can take as it evolves, and I'll be curious to see what Yahoo! does with it. One of the first things I wanted to do when I started working with Pipes is that I wanted to be able to construct and share new modules. I hope that it's something they would consider exposing, because man would that be tight! From personal experience, though, I know that it's probably not going to happen -- it's really hard to lock-down any kind of code that would have to execute in your process space, so that's probably out. But maybe if they could just expand the existing "Fetch" module so that one could POST the current state of the stream to an external URL that I host on a server somewhere and I could return the transformed content, and you could wrap that up in a sub-pipe that expects additional user inputs as the config parameters ... something like that could work.

Which brings me to the meat of this post: wonderful things could happen if you marry Pipes to the Atom Publishing Protocol (APP). What if the pipe output, rather than just being XML that spills on the floor when the URL is requested, could instead be hooked up to a module that speaks APP? Now you've got a really cool content routing mechanism. The "Fetch" module already really handles the input end of things, but being able to channel the output to a different destination could open up some amazing possibilities.

One detail to be worked out is the triggering mechanism for the workflow. Currently, a request to the resultant URL serves as the triggering mechanism that the workflow should executed. This is how FeedBurner works as well -- there's no master cronjob that ticking away and retrieving all the source feeds every 30 minutes. Instead, when a request for the burned version of the feed comes and the source feed is stale (i.e., hasn't been checked in the last 30 minutes), then go refresh the source feed. That way, you don't waste cycles updating dormant feeds. Pipes works the same way.

So, if there isn't a request URL, how would you "run" the workflow? Probably the most appropriate thing to do would be to use something like a ping mechanism, so that if the pipe is pinged and the content has been modified since the previous run, you run the pipe. That could probably work.

In the end, if you take the promise of Pipes, the potential of Google Base, and add some of the stuff that you'll see from FeedBurner in the next few months, you'll have some wicked tools to start rewiring the next version of the web. I think it's going to be quite a trip.

Last Thursday we had another hackathon at FeedBurner -- our fourth -- which is always an event to look forward to. This one was a lot of fun and there are some really cool hacks that are live right now. My hack was an "Event Feed" service, and I thought I'd write up a bit more information about how it works and how I hope publishers might use it.

First of all, like most good ideas, the idea for this one came from one of our publishers. This suggestion came from Jon Morris (Matis). He keeps his upcoming performances in upcoming.org and wanted a way to display the events on different web sites.

At first, it seems like this should be easy. Upcoming.org has feeds, and FeedBurner has BuzzBoost (not to mention several other widgety tools). Should be able to just burn the feed and choose BuzzBoost, right? Well, not quite. For some arcane reasons, the dates associated with the items are not the event dates, but instead represent when the event was added to upcoming.org. Turns out, that's not terribly useful for most feed consumers. Fortunately, they include other elements in the feed using the xCal namespace that includes information like the event date and location.

Enter the "Event Feed" service at FeedBurner. When you activate this service on the "Optimize" tab at FeedBurner, you're saying that the source feed represents a series of events and that you want them treated that way. So, what FeedBurner does for each item is:

1. Find the event date and make that the item date
2. Put the items in ascending date order (optionally only including future events), and
3. Optionally prepend the event date in the item title

So, Jon's case, his source feed isn't terribly useful. But if we burn it and apply the Event Feed service, we get a more useful feed. Finally, we can apply BuzzBoost to get an easy-to-distribute list of upcoming performances:

So far, so good. But I don't use upcoming.org ... I happen to use Google Calendar. And what good is a hack if it's not useful to the author?!? So, the Event Feed service will also work with public and private Google Calendars. You just have to find the RSS feed for the particular calendar you want, which can be a bit of a challenge sometimes. Hint: it's somewhere on the Calendar Settings page.

This will work for both shared and private calendars ... let's see how it works. Here's a public calendar: Chicago Bulls schedule. If you look at the feed, you can see it's not terribly helpful: events are totally unordered and it includes past games as well as future games. So, let's burn it and add the Event Feed service. Ah, much better. Here's a nice little headline animator for it as well:

Finally, after staring at those nice upcoming.org feeds complete with event location information, I couldn't resist tossing a FeedFlare into the mix. This was literally cobbled together in 10 minutes right before the end of the day -- I love how easy it is to create these things. Anyway, here it is: Map Event FeedFlare. Take a look: it's just examining the item and looking for the lat and long elements and the venue name, then composing a URL to Google Maps with that information in it. This is actually a good example of how you can use XPath to pull arbitrary information from other namespaces out of a feed item and use them in your FeedFlare. Here's an example of a feed that's using that FeedFlare: source feed, burned feed. And here's what it looks like in as a SpringWidget:

I hope you enjoyed this behind the scenes look at this hack. I had a great time building it and I can't wait to see what people do with it!

Looks like my new T60 widescreen will be waiting for me when I get home. I'm shivering with anticipation From Kowloon Bay to Arlington Heights in less than a week. That's cool.

We introduced a really powerful new capability at FeedBurner last week: custom Headline Animators. We're already seeing a ton of cool skins that people have created, and I thought I'd have a little mash-up fun with it ... introducing, the "Dream Date Dock Worker's Word of the Day" widget, brought to you by the OnDemand Action Figure Builder Tool, TheFreeDictionary.com, and FeedBurner.

In case you didn't notice, we've been growing our core catalog of FeedFlare at FeedBurner. We now have three very cool dynamic FeedFlare units that leverage other web services to help bring interactivity to your feeds and sites.

• Technorati Cosmos Links. Example: Technorati: 8 links to this item
• Scape This. Example: Vote at Netscape. 231 votes, 548 comments
• Digg This! Example: Digg This! (87 Diggs, 55 comments)

You can add one or all of these FeedFlare to your feed or site -- and remember that the information displayed is always current, without marking old items in your feed as modified. Just go to the "Optimize" tab of your feed and select "FeedFlare". Or, you can choose other FeedFlare from the growing, chaotic Flare Catalog ... or build your own!

The RSS Advisory Board approved a specification revision ... ahhh! What does it mean? How do I stay up-to-date??? Here you go, this is all you have to do. If you have a <docs> element at the channel level, just change it from this:

<docs>http://blogs.law.harvard.edu/tech/rss</docs>

to this:

<docs>http://www.rssboard.org/rss-specification</docs>

All set! As you can see, it's not a big deal.

Tom Carroll has a great list of things he's looking for in a feed management service. Let's see how FeedBurner stacks up!

"The migration to the service must be seamless for my current subscribers"
Answer: Yes ... see "Can I keep my original feed URL but still use FeedBurner?" and "Pointing an existing feed URL at your new FeedBurner URL".

"The service should provide a suite of metrics that allow me better understand who, how often, when, how long, how many times (You know what I mean, the numbers)."
Answer: That's the foundation of FeedBurner. I think you'll be pleased with the stats available to you.

"In the case that I choose to leave your service, I must be able to migrate my feeds transparently and also be able to migrate my usage data."
Answer: To leave, see "Ciao, FeedBurner". To export your usage data, see "Awareness API and Subscriber Numbers".

"I would like support for one click subscription to the various news readers."
Answer: See our Browser Friendly service. To see it in action, click on my feed in a browser.

"The service must have tight wordpress integration."
Answer: Please see Steve Smith's excellent WordPress FeedBurner Plugin.

"Integration with analytical packages say like Google analytics"
Answer: We don't have an integration with Google analytics, but how about Mint? And wait until you see what we have cooked up after we ingest Blogbeat!

"feeds must be human readable"
Answer: Again, see our Browser Friendly service.

"I would like it to support leave comment from the feed."
Answer: Use our "Add a comment" FeedFlare ... it's somewhere on this list of "101 FeedFlares for a Better Tomorrow".

"Configurable support for social network services like Digg or del.icio.us (Sometimes I want it on, sometimes off)"
Answer: FeedFlare to the rescue. You choose which services you'd like to add to your items in your feed.

"Support for the widest set of RSS extensions"
Answer: Yep. We support them. And all feed formats.

"A strong record of availability, reliability and scalability"
Answer: This is the most important quality of whatever you choose for feed management, and it's our number one priority. I think our availability track record shows that. We also have a number of contingency plans in place that we hope we never have to enact, like our "Feed Insurance" capability that all of our publishers get for free.

"Should support multiple feeds per site, no limit."
Answer: We support multiple feeds per site, no limit.

"Integration to see where my feed is bookmarked and subscribed"
Answer: Part of of our stats package includes the ability to see where the items in your feed have been read and possibly resyndicated. See "And There Was Much Rejoicing: New FeedBurner Statistics" for more info.

"Advertising, I prefer none."
Answer: No advertising, unless you want it and have a certain threshold of subscribers. See "Does FeedBurner put ads in my feed without my consent?"

I hope that gives you enough confidence to give FeedBurner a try, Tom!

I wanted to clear a couple of things up about the Redirecting Guy post. First, FeedBurner feeds never "expire": once you have a FeedBurner URL, it's yours until you explicitly delete it. Second, if you do decide to delete your FeedBurner feed, you can select the "30-day Redirect" option, which goes through the following steps:

Day 1-10: Any requests for the FeedBurner feed are sent an HTTP 301 "Permanent Redirect" response back to your source feed. This will cause most feed readers to forget the FeedBurner URL and use the new URL from that point on. Your subscribers don't feel a thing.

Day 11-20: If your FeedBurner feed is still getting requests at this point, it probably means that your feed reader is treating that "Permanent Redirect" as a "Temporary Redirect". That's actually pretty common, so now we enter "Phase 2". Now, any requests for your FeedBurner feed will receive a "redirect document". What is a redirect document? Dave Winer displayed foresight by anticipating this need back in 2002 and provided this specification so that a publisher could keep control of their feed location. We strongly encourage more feed readers to support this specification, and we are going to be widely campaigning for this capability.

Day 21-30: You're still here? Well, at this point we return a valid feed that contains a single item that says "This feed has moved to (feed URL here)". So even though all of the transparent mechanisms to redirect the subscription have failed, there's still a trail for your subscribers to follow.

After Day 30, your feed is deleted and that URL is up for grabs. If you would like to extend this time period beyond 30 days, however, just drop us a note to feedback [at] feedburner.com and we'd be happy to extend this redirect period indefinitely. We've done that for lots of publishers.

Mike's point is valid: as a publisher, you should be aware that if you delete your FeedBurner feed you are also releasing your claim to that particular URL, just like what happens if you give up a domain name or a delete a blog on a hosted service. We have provided the tools (through redirection, MyBrand, and the 30-day Delete process) to ensure that publishers maintain complete control over their feed, but we always welcome feedback and suggestions for improvement!

Good article in Business 2.0 on FeedBurner featuring Dick. I like that he worked in the "feed of me" stuff.

Source: Business 2.0: Branding the feed - Jun. 27, 2006

Bloglines recently announced much improved support for Atom 1.0 feeds. Therefore, at FeedBurner, we flipped the bit on the SmartFeed service so that Atom 1.0 feeds will be delivered as-is to Bloglines instead of being down-converted to Atom 0.3.

Very soon, we're going to be switching SmartFeed from the current "assume a reader doesn't support Atom 1.0 unless we have recorded otherwise" logic to the "assume a reader does support Atom 1.0 unless we have recorded otherwise". That might cause a few problems with some readers that we haven't identified, but we should be able to chase those down quickly.

This past Friday, we had our third Hackathon here at FeedBurner. My project was to create a FeedFlare development environment, since creating and debugging FeedFlare Units right now is like spelunking without a flashlight. So I created the FeedFlare Scratchpad as a rudimentary start to this development environment.

Below the fold is a simple walkthrough for how this tool works. I hope it helps some enterprising FeedFlare developers out there!

Continue reading "FeedFlare Scratchpad"

I know someone that is going to be very happy.

Michael and the Six Apart team did an awesome job with this integration with FeedBurner. Really nice work!

There's been a lot of chatter lately about FeedBurner, which is fantastic. There have also been some misunderstandings about how a publisher can keep control over their feed. I think we at FeedBurner can be a lot clearer about this, but until that happens I would like to point people to an older post I made called "FeedBurner on Your Terms". Basically, it details four different ways to hold onto your feed:

1. Use an HTTP temporary redirect
2. Use a PURL
3. Use partner domain mapping (now called "MyBrand")
4. Embrace the burn

Since that post, we have also added our Feed Insurance capability, which has been chugging along since we announced it, ready to spring into action if it's ever needed. Hopefully, it will never be needed.

FeedBlitz recently announced a very clever service called the FeedBlitz AutoResponder. The name doesn't quite describe what it does, imho ... it's really a cool way to offer a serial version of content to interested subscribers that is delivered over the course of several days or weeks. You basically set up a blog somewhere with the dates of the posts spaced out how you want them. Then, when someone subscribes, FeedBlitz delivers the posts via email on that schedule. Smart and elegant. At FeedBurner, we did something kind of similar with Tom Evslin to deliver his hackoff.com novel via a feed, but that was a bit hacky and hasn't been generalized yet. Nice job, Phil.

There is a very useful RSS extension that I've been using on this site for a long time that allows a "feed of comments" to be associated with each entry in a feed. I've been calling these "microfeeds", and the extension that allows this to happen is called the Well-Formed Web namespace elements. There are all sorts of cool things you can do with this element, including using FeedBurner's Comment Count FeedFlare, and this element has made it into the default WordPress templates.

So, what's the problem? The person who maintains the landing page for the namespace URI at http://wellformedweb.org/CommentAPI/ changed the element name from CommentRSS to CommentRss without really telling anyone ... and didn't change the date of the page from 2003-10-10! It's like the history eraser button. This is lame. Here's the reasoning behind the change from Joe Gregorio on the feedvalidator mailing list:

I changed the Well-Formed Web site after it was pointed
out to me that it disagreed with Chris Sell's Specification,
after all he is the author of the spec. I would have made a
bigger deal of it had I realized how many implementations
of commentRss there were.

Ack! Every time I've run into this element it has always been capital RSS ... because that's what the namespace's URI landing page said. Sure, that's not binding, but now this is really becoming a problem for publishers that want to validate their feeds ... and now all downstream consumers of feeds are realistically going to have to look for both variations. We've had to change our FeedFlare to look for both variations, for example.

So, for those following along at home, that is *not* the way to care for a namespace.

Today, TypePad introduced TypePad Widgets, which is a elegant handshake framework for being able to add things to the sidebar of your TypePad blog. You can test it out at FeedBurner by going to the "Chicklet Chooser" service on the "Publicize" tab of your feed ... make your selection and scroll to the bottom. We're planning on adding this functionality to every place in FeedBurner that generates an HTML snippet.

I really like the simplicity of this framework, and I hope it's the first of many steps from TypePad to open things up! I'm not sure why they have the API behind an application form, but it's probably just until all the kinks get worked out.

Today we announced the second phase of FeedFlare, which allows you to put the FeedFlare back on your site. To see an example, I've added it to this blog ... just look right below this item. The "Add to del.icio.us" and "View CC license" are generated by FeedFlare. They showed up because I put the following code (as directed by our help guides) in my Movable Type template:

<script src="http://feeds.feedburner.com/eric?flareitem= <$MTEntryPermalink$>" type="text/javascript"></script>

Now, if you're an MT junkie, you might not be that impressed ... "you could have just added the Flare things directly to your template". That's true. But for the majority of the users, what's really cool about this is that, once you've put that single Javascript call, you configure all of the settings from the FeedBurner UI. No messing with plug-ins, no rebuilding your site, no having to move to dynamic templates. And it's universal: you use the same interface to configure an MT blog as you do for a Blogger blog as you do for a WordPress blog. Once we release the third phase of FeedFlare, where we open up the API so anyone can create these FeedFlare, we'll really see the flexibility of this universal plug-in framework.

There's one other very powerful thing about FeedFlare on the site: we are using all of the metadata and expressive power of the feed to inform the FeedFlare on the site. Since FeedBurner is processing your feed, all of the structured information is available to help generate the FeedFlare on the site. No having to scrape an HTML page like other scripts are forced to do -- we can use the upstream information that simply isn't available in the final, rendered page.

I'm really excited about this new development with FeedFlare, but I'm really really excited about what's coming next. The API is going to be a lot of fun, and I can't wait to see the kinds of FeedFlares that will be created. So, back to work for me!

I'm going to have to side with Mark on this one ... there are just too many examples of Apple not getting it. It's time they got it.

I sure miss Mark's blog, but his mailing list posts almost make up for it!

Source: Sam Ruby: Photocasting Hyperbole

Even though the title of the post is "FeedBurner's Dick Costolo on RSS Ads", this is a good Q&A about more than ads. Nice job, Dick!

Source: Interview: FeedBurner's Dick Costolo on RSS Ads

Apple, what are you thinking? First off, the good: movie trailers are a great idea for the new iPods. They even have a nice page that lists a bunch of trailers: cool.

Check it out -- an RSS feed for this page. Alrighty, they must be podcasting the trailers so you can subscribe to it right in iTunes, complete with the iTunes namespace extensions. Great idea, Apple.

Then I looked at the feed:

<rss version="0.91">
<channel>
<title>Apple Movie Trailers</title>
<link>http://www.apple.com/trailers/</link>
<description>Popular movie trailers presented in QuickTime.</description>
<language>en-us</language>
<copyright>Copyright 2002, apple.com.</copyright>
<item>
<title>Chicken Little</title>
<link>http://www.apple.com/trailers/</link>
</item>
<item>
<title>Harry Potter and the Goblet of Fire (Trailer 2)</title>
<link>http://www.apple.com/trailers/</link>
</item>
<item>
<title>Syriana</title>
<link>http://www.apple.com/trailers/</link>
</item>
...


RSS 0.91? No enclosures? No itunes elements? Everything linking to the same URL? There's not even enough information to run this thing through SmartCast.

Apple movie trailer page people, if you'd like to enable this feed for podcasting, please let me know and I'd be happy to help. As it is now, it's ... well, a little shameful.

I understand that geeknews doesn't like FeedBurner, and I can respect that. But I want to make sure that people's opinions of FeedBurner are informed by accurate information, so I just wanted to respond to a few of the comments on the post "Why would 100,000 people trust their RSS feed to FeedBurner".

"It is well known that an update on a site does not necessarily mean that feedburner is going to know about it immediately."

That's true unless you ping us. We will poll your feed every 30 minutes, so it's possible that your burned feed could be up to 30 minutes stale. To update your burned feed instantly, you have a number of options:

• Configure your blogging software to ping FeedBurner at http://ping.feedburner.com. Here are instructions to ping FeedBurner in Movable Type, but other blogging platforms have a similar capability.
• Use our FeedBurner ping form to let us know. You can also bookmark the result page to ping us by visiting the bookmark.
• You can also use Ping-o-Matic with FeedBurner.

"...you have no idea if they go offline and they don't graph any outages"

We actually haven't had any downtime since June 25 when our colocation center got hit with a power outage. We pride ourselves on our availability, and we're always seeking to eliminate points of failure like this.

We will, however, notify you if there's ever an outage with your feed. Every publisher gets their own personal feed (called "FeedBulletin") where we will proactively notify publishers if their source feed is ever invalid or unreachable. You can visit your "My Account" page on FeedBurner for more information on this cool feature.

"...the statistics are never truly accurate."

Much like web stats, feed stats are an inexact science. We think we have the best understanding of all the different aggregators and their unique polling characteristics, but we're constantly learning and improving our algorithms.

One place we definitely want to improve is our podcast statistics. Currently, we don't track downloads to the enclosures themselves. That's something we're working on.

"I tired it and never got accurate Stats on podcasts listened to, not only that your statistics are public. I got nothing to hide but My stats are not everyone elses bussiness"

Point taken on the podcast stats (see above). But your stats are most definitely not public unless you as a publisher choose to make them public. By default, your stats are private. If you choose to enable the Awareness API, then your stats are made available to feed and podcasting directory services, which has been a boon to many podcasters.

"...but the question remains why would 100,000 people trust a third party to update and maintain the lifeblood of the one single document that connects most sites to their readership."

There are a number of ways that the publisher can keep complete control over their feed URL, so if we ever disappoint we can be cut out of the loop instantly. That just means we have to work hard to keep publishers very, very happy.

That's all for now. We're always open to suggestions for how we can improve our service. I'm going to put the cape away and return to fight FUD another day.

I'll write more about this in a later post, but if you're a FeedBurner user there's one thing you have to go do right now. Go subscribe to your personal feed. Go to your account page on FeedBurner, find the URL of your personal feed, and add it to your reader. You won't regret it. It will tell you if your feed is ever invalid or unreachable by FeedBurner.

It our way of communicating with you without you having to give us your email address. You control the conversation. But we have some good things to say, so please subscribe!

I had the opportunity to talk with Brian Livingston recently about RSS, and he just wrote up his article RSS Readers: Narrowing Down Your Choices. Brian was a very interesting guy to talk with and he wrote one of my all-time favorite computer books, Windows 95 Secrets.

It was a pleasure to answer the thoughtful 5 Questions with FeedBurner CTO Eric Lunt over on SearchViews. Be sure to go check it out.

I was looking through some of the FeedBurner stats the other day and noticed a cool feed that's quite timely: the USGS M>2.5 Earthquakes feed. Those of you in California might want add that feed to your reader!

Reminds me of one of the popular Spyonit spies we had in the summary of 2001: the CA Rolling Blackout Spy. You left-coasters have all the fun.

I've been meaning to write this post for a while ... it probably belongs somewhere on the FeedBurner site, but I'll just put it here for now. I wanted to document exactly how and when FeedBurner will rewrite <link> elements in feeds.

First thing you might be thinking is "Why is FeedBurner rewriting links?" Well, one of the service that we offer to publishers is "clickthrough tracking", where we report the number of clickthroughs on a per-item basis. To do this, we rewrite the URL associated with the item and when it's clicked on, we log the click and then forward it on to the original item URL.

The second thing you need to know is that we never rewrite the <guid> element in an RSS 2.0 feed, although we may switch the isPermaLink attribute from "true" to "false" in some cases. The guid element is used in many cases to unique identify a feed element, and we don't want to mess with that.

Last thing to know is that if we ever rewrite the link to an item, we'll stick the original value of the link in a <feedburner:origLink> element, which is useful for some search engines and other consumers of the feed to reconcile items that may be syndicated into multiple endpoints.

If you want more details on exactly how the rewriting works, it's in the extended entry.

Continue reading "How FeedBurner Rewrites Links"

I'll be at the Syndicate conference in NY next Tuesday and Wednesday. Hope to see you there!

Dare has a great post that talks about all the great things that can happen when sites agree upon a standard content interchange format: RSS. A nice companion post to Jon Udell's from about a month ago, previously mentioned.

I still think there's a pretty decent chance that Atom will supplant RSS in 12-18 months as the interchange format of choice, simply because the standard nouns (the Atom Format) are coupled with standard verbs (the Atom API), but you never can tell in this business!

I tend to listen very carefully when Adam Bosworth speaks (like those E.F. Hutton ads for you old timers). He has the unique combination of a wide perspective and a deep understanding of what it takes to realize a vision.

Source: Dare Obasanjo aka Carnage4Life - Adam Bosworth's Web of Data: Is RSS the only API your Website Needs?

Looks like My Web is Yahoo!'s answer to del.icio.us. Gather links and search results, publish your My Web links via RSS, and use the API for My Web. It's a beta and it shows ... del.icio.us is still miles ahead.

But here's some specific feedback on the RSS feed that is available for the shared folder.

Continue reading "My Web RSS Feedback"

I think it's funny when people say that feed formats are really irrelevant because all of the readers support all of the formats anyway. While that happens to be mostly true right now, the new, non-backwards compatible Atom Format spec is going to be released one of these days, and we'll be right back to the chicken-and-egg problem of publishers not wanting to convert their feed to the new version until it's widely supported in the readers, and the feed readers having to prioritize adding support for the new format and managing a release.

I think SmartFeed is going to be a big help in helping publishers manage that transition. When the spec is released, we'll make sure that SmartFeed "down converts" the new spec to the existing 0.3 spec for readers that haven't been upgraded yet.

What's in store for Format Wars, Episode 4 you think? I'm thinking it's going to be in reconciling different namespace extensions for rich media types. Different music namespaces, photo namespaces, video namespaces ... and how about enclosures vs. Y! RSS Media extension for the next generation of podcasting? All coming soon.

We've been patiently waiting for the Google AdSense in RSS news to leak out, and it looks like it has. Google's approach is straight-forward: you edit your source feed template and modify it so that you include a linked img, the src of which includes the URL of the permalink associated with that item. That piece of markup gets generated once, and the img that returns can change over time. That prevents the feed from being marked as modified if they want to change the ad that gets slotted for an item.

FeedBurner has had a framework like this in place for quite a while, and we're excited to be able to add support for this program, which we detail in the post Google AdSense Support. Our offering will open up this program to user's that can't edit their feed template, but we can add a bunch of value to all publishers. Using FeedBurner to add your AdSense ads will give you a number of additional configuration options, like:

• only including ads in posts of a certain length (at least 100 words, for example)
• including in alternating posts instead of every post (if you're worried about advertising overload!)
• choosing which categories/tags to add ads too (include ads in my "venture capital" posts, but not my "family" posts)

The most exciting thing we can do, though, is integrate your ad performance statistics with your existing FeedBurner stats. Wait until you see our new Total Stats PRO paid offering -- you're gonna like what you see. Ad performance on a per item basis anyone?

Anyway, as John Motson likes to say, "things are hotting up now!" It's so much fun to be in this space right now.

Jon, as usual, gets it. Increasingly, companies will have to defend their choice to not represent their content as RSS as it becomes the standard content interchange format. OpenSearch, as mentioned before, is an excellent example.

Source: InfoWorld: Using RSS for data integration

So, this "item" shows up in my Feedster result feed for FeedBurner:

That seems pretty slimy to me. I have no issue with these SimpleFeed people buying the "Feedburner" adword ... in fact, that's kind of flattering. But to have "Feedburner" displayed within the item itself is misleading, and I hope people don't get the impression that we have anything to do with them.

Harrumph!

Amazon introduced OpenSearch at ETech yesterday. Awesome. It just goes to show you that RSS is becoming the standard transport for content, and this is a great example of how RSS is getting more and more valuable as it gets more and more invisible.

I wanted to dig into OpenSearch a little bit, so that's just what