The last little while, I’ve been doing a lot of infrastructure shifting, and I’ve realized that in the world of computers, USB is maybe the greatest standard ever. I’ve heard kernel engineers sneering and scoffing, but here’s the highest compliment I can pay, speaking as a fairly hard-core computer tech type: I have no idea how USB works, and I don’t think I’ll ever have to learn. If the plug fits into the socket, whatever I’m plugging in will do whatever I’m expecting it to do. I think syndication ought to be like that, which is why Eric Garrido (via Bill de hÓra) is right: please stop announcing multiple syndication-file versions, because nobody cares. Pick one and run with it. I’d say pick one that’s standardized and stable and debugged and modern, but whatever.
Contributions
Comment feed for ongoing:
From: Danny (Apr 07 2008, at 03:30)
"It Just Works" is definitely a good target, but I can't really agree so much with your example thanks to recent experience with USB. Because of other issues I'm obliged to run WinXP on the machine in question, and the USB drivers for MIDI kit seem very flaky. My only recourse in this situation would probably be to take it up with MS... So for me at least a modern - easily debuggable - syndication format is a considerably better design than USB.
Incidentally, Eric Garrido lists all the popular feedreaders as supporting Atom 2.0 - what did I miss?
[link]
From: James Justin Harrell (Apr 07 2008, at 07:10)
You seem to be comparing webfeeds to USB. I think a better comparison would be webfeeds (RSS, Atom) to general purpose data connectors (parallel, serial, USB, firewire, etc). Most people who use webfeeds don't know any more about RSS (or RSS or RSS) or Atom than they know about USB and firewire. They only know there is more than one format.
[link]
From: Rob Russell (Apr 07 2008, at 07:22)
Interesting way to frame a compliment, and I have to agree. I know a lot less about USB than I do about most of my computer's guts but I never realized what that implies as far as the protocol goes.
[link]
From: Avi Flax (Apr 07 2008, at 08:37)
@Danny, I think that's more an issue with specific drivers for that specific device, rather than USB itself. USB is just the interconnect and transport "protocol" for a given device - the manufacturer still needs to provide decent drivers, if the device doesn't use a standard configuration that most OS's recognize (FAT32, PTP, etc).
[link]
From: Steve Loughran (Apr 07 2008, at 09:16)
If USB is so wonderful, how come it never recognises the locale of the keyboard? Why can't I have a US keyboard on the laptop, plug in a UK USB keyboard and have both coexist?
it may just work, but some of the design decisions were made a long time ago, and were done to make the migration as low cost as possible, without thought to the long term benefits of a bit of extra information, such as the locale/layout metadata of a keyboard.
[link]
From: PatrickQG (Apr 08 2008, at 01:36)
The complainers here seem to be mis-directing their hate: it's not USB that's the problem, its your drivers/OS of choice. If it can't handle multiple devices being attached with different settings, don't blame USB for that.
USB is, basically, just a bus that happens to have some requirements for the device to identify itself and any common profiles it supports. It's up to drivers (either supplied by the OS/product vendor, or, of course, yourself)
And yes, I'm aware that the independent keyboard-locale issue affects Mac OS X as well (I happen to have a US keyboard in the MacBook Pro and have a UK wireless one at my desk, I just use the US layout all the time).
[link]
From: Charles Hoffman (Apr 08 2008, at 06:36)
I wanted to make you aware that the US Security and Exchange Commission (SEC) has provided an ATOM feed for every company or person who files with the SEC. This is REALLY slick. The SEC is also working to move SEC filings to an XML format using XBRL.
For more information, see: http://xbrl.squarespace.com/journal/2008/4/5/the-sec-they-totally-get-it.html
Or, you can look at any SEC filer, see: http://www.sec.gov/cgi-bin/browse-edgar?company=&CIK=msft&filenum=&State=&SIC=&owner=include&action=getcompany
[link]