The best tech city in the US is not New York. For one very simple reason.
The Internet service in NY, for the average home, on average, sucks.
I'm using Time-Warner now. It's the only option for most NYers (or something like it).
NY has internet for consumers. It's no good for creators.
If you want to tell an application where the RSS feed for the site is, include a <link> element in the <head> section of the HTML document with the following attributes:
1. rel = "alternate"
2. type = "application/rss+xml"
3. title = "RSS"
4. href = the address of the feed.
For example, this is the link element, which is included in the head section of every page in this blog, that helps you discover the feed.
<link rel="alternate" type="application/rss+xml" title="RSS" href="http://scripting.com/rss.xml" />
Note: This feature has been around since 2002, but I didn't have a current page that explains it. The original page is on the Radio UserLand site.
0. Disclaimer. Rather than hold my conclusions to myself, it's better to put them out there and let them be debugged publicly. None of this is personal, so I hope people don't take it personally.
1. The oEmbed spec documents two ways to get from the HTML source of a page to the content it contains. One method is simple, let's call it the link method. I could implement it in an afternoon for the Scripting2 blogging software. I have something very much like it, already working. Each story on this site, including this one, has a link to an OPML document. From there, any kind of rendering is possible. The key thing is I'm getting to all the content of the page, with none of the overhead/template stuff. One link element in the HTML is all it takes to make this work.
2. No one implements the simple way. They all do the complicated way.
3. There's a short list of service providers included in the doc. Pragmatically, if you want to be part of the oEmbed club, you have to get them to list your service in the implementations section of the spec. Otherwise how would people find out about your service?
4. The simple way of doing it has ample prior art and works well. We use it in RSS for connecting feeds to HTML pages. And for RSD, which tells editing software who to call to edit the source of the page (which seems fairly related to oEmbed).
5. I think the security argument is bogus. The oEmbed spec has a section that explains how to keep a bad actor from doing a XSS exploit or accessing cookies they have no right to access.
6. The security argument is no different from the argument against embeds in general. We embed tweets from Twitter or videos from YouTube without questioning what they might inject into our reader's browsers. Why does WordPress trust them more than they trust me? I think this problem has to be addressed in some other way.
7. I would deal with the security issue differently. Strip all markup. And use a structural format like OPML so the way the page is arranged can be transmitted without taking any risks that something nefarious is coming along for the ride.
8. If I implement it I will only use the simple method. I don't see any upside in using the complex method. I will listen to what the oEmbed spec says to do from a security standpoint.
9. I also include a link to the OPML in my RSS feed. Screen shot. I want you to find it, so I leave little hints around everywhere I can think of.
Anyway, that's my thinking on this for now.