"I've noticed that whenever I have a photo on Flickr that I want to embed in my blog, I make a local copy and link to that. Flickr may well out-last the Fishbowl, but at least the continuing availability of my webserver is something that I have a say in." -- Me, a few minutes ago.
I registered the
pastiche.org domain back in 1997. Since then I've been through a half dozen or more ISPs and hosting services, but I've done so secure in the knowledge that so long as I keep paying my domain renewal fees, my email address, website and whatever other Internet perks I feel like having will follow me wherever I go.
(There are disadvantages, of course. Even for a non-entity such as myself, eight years of being careless with the one email address leads to a lot of spam.)
I had this conversation with a friend, and they told me not to worry: Gmail is likely to survive longer than I'm going to need an email address anyway. But that's not the point. In five years, Gmail is going to be what Hotmail is today, and there will be another service that's cooler and more capable that people will rather be keeping their email in.
"Letting somebody else own your name means that they own your destiny on the Internet.... As soon as you realize you're serious about blogging, move it away from a domain name that's controlled by somebody else. The longer you delay, the more pain you'll feel when you finally make the move." -- Jakob Nielsen's Weblog Usability mistakes, #10.
Recently, Australian politician Malcolm Turnbull proposed that the government give each citizen a lifetime email address. There were obvious flaws. The proposed address scheme -- first name, surname, date of birth -- consists of two pieces of data that can change, and one that people often want to conceal. Also, there are many circumstances where one might need to mask one’s identity or create a new one (for example, to escape an abuser). Regardless, the underlying concept of a 'digital identity' that stays stable as long as you need it to is an important one. After all, cool URIs don't change.
If there's a Web 3.0, it's not going to be about giving you cool sites to put your stuff on "out there", but about giving you the tools to build that cool stuff on top of your own persistent, personal space on the net... in a way that when the services change, the technology advances and the trends turn, the stuff stays where it is.
# The iTunes Music Store was released in Australia today.
- Lots of Australian content on the store from day one
- I can now legally get hold of a whole lot the songs that have been rattling around my head, but that I didn't want packaged with a whole album of filler.
- It's just nice that I no longer feel like we're the only Western civilisation without an iTMS.
The Marginally Good
- AU$1.69 price for singles is better than I feared it might be, but even taking GST into account, we're still paying 15% on top of the US$0.99 standard.
- Similarly, the AU$17 standard for albums is significantly cheaper than you'd pay for a full-price CD, but a lot more than you could pick one up for at, say, Dirt Cheap CDs
- Sony are still throwing a tantrum over the iPod eclipsing the Walkman, so anything up to a quarter of the music which should be in the store, isn't
- All EMI albums seem to be "per song only", which means you can't buy the album... which leads to a rather ludicrous situation when you take album-only tracks into account. (Note: As of Friday 28th October, this is fixed an EMI albums are available for purchase.)
iTunes Music Store Australia scores a dismal 6 out of 10. Which would be really bad if all the other Australian digital music stores didn't rate down around 2.
"We’ve gone from having no control over the source, to having no control over the entire application." -- Rektide, in comments at O’Reilly Radar
I've noticed that whenever I have a photo on Flickr that I want to embed in my blog, I make a local copy and link to that. Flickr may well out-last the Fishbowl, but at least the continuing availability of my webserver is something that I have a say in.
- Wherein Charles makes up some flimsy excuse to link to a Kevin Marks post about tagging and keywords
- Wherein Charles makes flimsy apologies for the encroachment of marketing on that sacrement of development - the version number.
(See also Mark Pilgrim: "A corporate blog is just like a personal blog, except you don’t get to use the word 'motherfucker.'")
# The other week, BRW named Atlassian Software Australia's third-fastest growing small business for 2005. Well, the third-fastest of those businesses that let BRW see their numbers. Over three years.
Still, if I hadn't spent all that time putting stupid things on the Internet, maybe we'd have cracked #2?
Because everyone else is doing it, here's my impression of Serenity.
I've never seen Firefly (something I plan to correct over the next week or so), so I went into the cinema with nothing but a hearty respect for Joss Whedon, and some rather high expectations fueled by a lot of talking up on the Internet.
I left... conflicted.
I really enjoyed Serenity, but I enjoyed it despite its many flaws. On one hand, the movie was too ambitious. It tried to fit a season of television exposition into a two-hour movie, on a third of budget of comparable sci-fi blockbusters, and came out feeling cramped and rushed. On the other hand, the ambition of the movie also made the whole bigger than the sum of its parts: if Whedon had settled for less scope, or been more timid with his budgetary constraints, he would have made a lesser movie.
The best example I can think of was there were too many characters. Eight is a great number for a TV show, where each week you can shift the focus to a different set of relationships. For a movie (unless you're planning a trilogy of three-hour epics), you can't fit that many people on screen for enough time to give them the development they deserve. No character had enough time to truly stand up, and some (such as Mal's love-interest) could easily have been cut entirely, if it weren't for the need to keep the fans happy.
On the other hand, even given their limited opportunities, most of the characters were invested with far more depth than most sci-fi movies afford their heroes. You still got a good sense of who they were and where they were going. You knew enough to care about them. Time was even spent out fleshing out the bad-guy, who could easily have just been a cardboard Terminator, but for whom you were forced to feel a twisted, sickening empathy.
And that, ultimately, is what's good about Serenity. When was the last time you read a review of a science fiction movie that talked at length about the characters? Despite all its baggage, it's a good movie - in turns tense, enjoyable, exciting and funny. And if everyone goes see it, Whedon will be given more money to make the next one with less baggage attached.
Three and a half stars out of five.
OPML is the Outline Processor Markup Language - an XML dialect invented by Dave Winer as a serialization format for outlines created in Userland applications such as Frontier. Winer continues to evangelize the format, and it has made its way into a number of applications: for example many RSS readers use it as an export format for feed subscriptions.
Occasionally, someone will come up with a problem that looks vaguely outline-like: "I need to store data nested inside other data", and suggest OPML as a possible solution. Predictably, the next thing you will hear is the pained cry of a large number of developers shouting "Please, God no."
The reason for this is that OPML, as specified, is a non-format. It's the alluring vapor of a specification that isn't there. Here's a simple demonstration.
The OPML specification can be found here. It defines the following:
- A top-level XML element: <opml>
- A <head> section, containing a title, and a number of presentational elements1
- A <body> section, containing one or more <outline> elements. <outline> elements can be nested
- Four "standard" attributes of the <outline> element, being:
text, containing arbitrary text: the 'content' of the outline node
type, containing arbitrary text describing, in some way that isn't defined in the specification, how a processor should interpret the node
isBreakpoint, which describe functionality specific to Frontier.
To allow the format to be flexible and extensible, OPML producers can add arbitrary attributes to outline elements. While types and attributes are arbitrary, the specification does not provide implementors a mechanism for finding out the meaning of either.
Here is a sample <body> section of an OPML document, cribbed from various sources to show different 'types' of outline.
<body> <outline text="Here is a Podcast that I found today" created="Tue, 10 May 2005 17:30:20 GMT" type="link" url="http://www.example.com/blah.mp3"/> <outline type="heading" text="This is my blogroll" created="Sun, 02 Oct 2005 04:18:09 GMT"> <outline text="Bruce's Weblog" type="rss" xmlUrl="http://www.example.com/rss.xml"/> </outline> </body>
You'll see above: three different 'type' values (remember, types are arbitrary strings), three different sets of attributes (also arbitrary). Let's play a game, and make a very simple transformation to the above document fragment:
<body> <link created="Tue, 10 May 2005 17:30:20 GMT" url="http://www.example.com/blah.mp3"> <text>Here is a Podcast that I found today</text> </link> <heading created="Sun, 02 Oct 2005 04:18:09 GMT"> <text>This is my blogroll</text> <rss xmlUrl="http://www.example.com/rss.xml"> <text>Bruce's Weblog</text> </rss> </heading> </body>
Given the OPML spec, and the above examples, we can now ask ourselves a simple question: What is the difference between accepting OPML, and accepting arbitrary XML documents of unknown formats?
Answer: An OPML document limits where you can put text nodes.
That's pretty much the only difference. Semantically speaking, there's no difference between <outline type="blah"> and just <blah>, and given the complete lack of specification or limitations on element attributes, that's all OPML is: an arbitrary XML document with limitations on where text nodes can go. The supposed value of OPML — that it defines an outline — is an illusion. An outline is stuff nested inside other stuff. So's XML.
Any interoperability between OPML documents is the result of largely undocumented conventions. Essentially, it comes down to the fact that a limited number of applications (mostly from the same set of vendors) produce OPML. So in order to process OPML, you just familiarise yourself with those vendors' conventions and choke as gracefully as possible on everything you don't recognise.
No wonder that potential implementors throw up their hands in despair. Imagine, if you will, the following conversation:
Manager: I want the product to accept XML documents.
Developer: You... what? But XML is just a format, how am I going to know what the documents mean?
Oh, that's easy. Here's some examples of some XML documents I've found on the web, work it out from them.
But how can I be sure I'm understanding them properly? What happens when someone gives me a document I don't understand? What if two people come up with documents that look similar, but follow different conventions?Oh, we'll cross that bridge when we come to it. I'm sure you're clever enough to deal with these things.
1 Many criticisms of OPML get sidetracked with how bad the presentational data in the header is2. However, given the larger problems with the OPML non-standard, all these complaints are trivial.
2And it's pretty bad. For example, to understand how to serialize node expansion states, you need to understand what "navigate flatdown X times and expand" means. And if it means what I think it does, then every time you expand or close (or move, add or delete) a node, you have to re-calculate the expansion states for the whole document below that node.
Assbandit: n. Literally, one who steals asses.
In colonial times, with dysentery being a far too common cause of death, a lucrative black-market arose around the trading of asses. A freshly harvested ass could sell for several pounds. Ass-bandits roamed the countryside, accosting travellers and making off with their asses.
In the Australian outback, so-called 'rumprangers' sometimes became local celebrities, and even national heroes. The most celebrated was Ned 'four-cheeks' Kelly, whose famous last stand involved him striding out to meet police in body-armour constructed entirely out of asses. Unfortunately, he soon discovered that the ass, as versatile as it is, is not bulletproof.
In America, local laws named this crime 'Highway Ass-Robbery', and thus the term 'Hershey Highwayman' was coined.