The things that bother me about Thunderbird on OSX are certainly many, but I can come up with one above all others that totally kills me: the lack of integration with the Apple address book. Nothing more than this illustrates the source of Tantek’s fervor for wanting data portability and his resultant hope in microformats.
Think about it. If Thunderbird stored hCards, and Address Book.app read hCards (or used them as its storage format), there’d be no problem.
One format to rule them all: XHTML! Best of all, you could use Spotlight, Applescript, and whatever other Mac-centric technologies on this data as well. No weird one-off formats that nothing else supports, no conversion, no special readers or parsers… and you could upload your address book and view it on the web… anywhere.
Factory Joe 
I would be already happy if Thunderbird would support good old vCard for its address book. (There seems to be a stalled attempt at http://vcard.mozdev.org/)
I agree.
Wouldn’t it be cool if it was at least XML, or even XSL with Ts!?!?!? XHTML would make it purposed, instead of universal, though. Am i right?
I’m all for standards, though.
Speaking of which…
I think that Apple should release their software as well, for free, so that the ipod software becomes standardized, but perhaps there’s more to the equation than i realize…
That’s a great idea. It would even be good if they did that on the Microsoft side. That way it would make it way easier for me to transition over to OSX.
Microformats are about extracting information from web-published data, not for backend storage systems, which is what the Thunderbird and Apple address books are.
Thunderbird is cross-platform and doesn’t have any bindings for _any_ platform’s address book (Windows Address Book, Evolution, KAddressBook etc.), so there’s no win at all by moving to hCard – you’d have to get every single other application to also switch and then you’d still have to have the bindings so that the applications could actually share that information.
hCard is a 1-1 mapping of vCard, the IETF standard for personal data interchange, presumably Apple’s address book supports this (the others I mentioned do, although of course, Thunderbird peskily doesn’t! You can still use http://labs.brotherli.ch/vcfconvert/ though). Plenty of applications also have great joy in sharing this information with other applications.
“no special readers or parsers” – er, except implementations of HTML parsers with hCard extraction code baked into every single mail and address book piece of software in existence? 😉
Sorry, just feeling picky 🙂
Phil, I think I disagree with your characterization of microformats. Or perhaps with your characterizations of the Thunderbird and Apple address books. At least as an end user, they provide a more convenient interface for sifting through data. The representation of that data on the backend isn’t really that important except when it means that I have to maintain two sets of data.
Since we have the vcard standard, everything *could* be stored as vcards… but that limits my ability to view that data in a reasonable, configurable manner without, again, having some specific tool like either of the address books.
My desire in having the backend data (which in the case of addresses is fairly simplistic data) be stored in browser-consumable XHTML allows me to access, edit and manipulate the data more easily than if stored in some other more opaque format… so while I shouldn’t have to care how my data is stored and it should “just work”, it doesn’t! So standardizing on a non-proprietary, open and easily consumable format seems a step towards solving this problem… and opening up the possibilities for many other applications!
First of all – sorry, I was in a bad mood the other day. 🙂
Secondly:
“Microformats are … Designed for humans first and machines second”
“Microformats are not … an attempt to get everyone to change their behavior and rewrite their tools”
“but that limits my ability to view that data in a reasonable, configurable manner without, again, having some specific tool like either of the address books.” – this is for you, of course. To someone who knows vCard and not HTML, or doesn’t know either of them, the opposite is true, and the address book would be indispensable if the backend was in hCard.
Your problem, as expressed in your post, isn’t about what the format used is, it’s about the ability of applications to interoperate.
“Think about it. If Thunderbird stored hCards, and Address Book.app read hCards (or used them as its storage format), there’d be no problem.”
Substitute A.N.Other format for hCard, and you still reach the same conclusion that “there’d be no problem.”
Oops, sorry – the first two quotes are from the Microformats website and wiki respectively.
Phil, in general, you’re right. I guess the benefits of my proposal are: using HTML to mark up this data means that I can toss it into a web browser or onto any remote space and, with a little CSS, read it nicely formatted — vcard isn’t stylable, so fails in that respect.
Additionally, the interoperability angle is definitely the thing which got me on this topic first, so you’re right, that’s what I mostly care about… but of all the possibly formats we could use for interoperability, as you suggest, hCard seems to me the most interoperable — across all apps! I mean, let’s say that we use some binary format to store this data — that doesn’t help me one bit if I want to go in and edit that information or, let’s say, copy a portion of it into a blog post.
I guess what I don’t understand about your point is why you seem to not want to use microformats for the purpose I suggest… HTML seems to be a pretty portable format at this time in history. I would say that most people coming out of school today can read and write HTML, native vcard? Not so much.
So in the interest of putting humans first, computers second, I think my idea actually espouses that core principle!