Atom: The Fatal Flaw No One Has Yet Noticed
Now given that atom doesn't really exist yet, it may be early to make a draconian statement like "Fatal Flaw" but this is fairly awful from my perspective. I was being interviewed for Under the Iron and the interview brought this to my attention. The (most excellent) question was:
Q: When Atom/Pie/nEcho is officially a spec and people start to use the real extensive metadata possible with it, will you need to adapt Feedster to searching more efficiently? Also, since Atom/Pie/nEcho supports content as sound files, pictures and even video, do you plan to look into those files and index their metadata as well?
For the answer to the 1st part of the question, you'll have wait for the interview. But the flaw to me was here "Atom supports content". Now I don't have any problem with content being supported -- but -- Atom supports encoded content. And that, to me, is a fatal flaw.
Here's the entry from the Atom wiki at: http://www.intertwingly.net/wiki/pie/content?action=highlight&;value=encoding. And here's a sample entry:
<content type="multipart/alternative">
<content type="image/jpeg" encoding="base64">
xo+Hello0AFWeblogh5FWorldh1mImagedsTbrVbF3
</content>
<content type="text/html" xml:lang="en-us" mode="escaped" rel="fragment">
<![CDATA[<p>Hello, <em>weblog</em> world! 2 < 4!</p>]]>
</content>
<content type="application/xhtml+xml" xml:lang="en-us" rel="fragment">
<p xmlns="http://www.w3.org/1999/xhtml">
Hello, <em>weblog</em> world! 2 < 4!</p>
</content>
</content>
Now if you notice the "base64" I'd have to assume here that they actually intend to support an image file within the RSS feed. Now what happens when people start to actually use this. You'll see issues like this:
- Every single user has to download that image. Even if they don't want it. This both increases bandwidth and removes control from the reader. It makes syndication more like email. Oh that's a good idea ! Sheesh.
- Bandwidth usage with increase for everyone -- provider and reader.
- There's no way to control who downloads that image (or video or audio) -- its all in the one syndication file and you have to download the file to see it
- If users are disabled (blind or hearing impaired) they still have to get the media. That makes sense. Yeah sure it does. What was Mark Pilgrim thinking? He even understands these issues.
- What happens when someone embeds something illegal or a pirated audio or video clip into their syndication file? Who's liable? At least when its linked you can choose not to follow it. Now you could end up with stuff on your hard disc you have no idea was there. And don't think it won't happen. What about pr0n in the workplace?
- When you're a blog author do you have to choose every time that you want a media item to go in your feed or as a linked item? Sure there can be defaults but what you really want is your tool to say something like this:
This jpeg is 1.2 megs. Your feed is downloaded on average 2500 times per day and this will cause X megabytes of bandwidth to be used costing you $154.37. Do you want this in the feed where everyone will see it or as a link where only 25% (expected probability) will click on it.
Shame no one will ever write that dialog box. Good for hosting companies though. Sure I want to give them more bandwidth.
- Let's play "Crash that Aggregator"! Just wait until someone starts fiddling with encoding options and your aggregator is told to expect a jpg file and gets an EXE instead. Think email is a security minefield now? Guess what -- your aggregator is headed the same way if it supports encoded content.
Atom support for encoded content. What were they thinking ? Sounds good in theory but in practice? Yikes. Just because you can do something technically doesn't mean you should.
When:
9:34:30 AM |
Permalink:  |
|
IM Me About This
|
(gif) 
(png)
