[untitled]

Today's Sunday Telegraph has an interview with Gore Vidal. Does he think there's immortality in books?

"I would doubt it now. Do you see anybody reading anything in the near future? The book is almost irrelevant. Poetry has the best chance. Fiction, I'm not so sure. I see the essay as probably the last necessary form of prose. I can imagine Montaigne outlasting Shakespeare, who will have become too difficult."

Weblog entries must be amongst the most transient of writings.

[untitled]

I've just come back from a fabulous holiday in Austria, where I was woken each morning by cowbells, as the cows from the farm where we were staying meandered down the road to their green and pleasant pastures. Hiking in the mountains, we would sometimes come across large numbers munching away, and it would sound like a wind-chime factory.

It's a wonderful thing that nobody has yet replaced these bells with electronic beepers, or even silent radio beacons. This is a fabulously appropriate technology, a location system which uses no electricity, is rugged and weatherproof, and actually enhances the environment in which it is installed.

So here's a challenge to mobile phone manufacturers: Can you produce a phone which, as well as being small, light etc, has a ringtone which does its job of alerting the user, while actually being pleasant to listen to? By 'pleasant' I mean actually pleasing, rather than 'not annoying'. You could use that built-in microphone to choose an appropriate volume level, too. Oh, and I'd like mine to play extracts from The Sound of Music, please.

MacJournal

I’m experimenting with MacJournal, considering it as an alternative to my paper notebook (which I don’t seem to be able to search with Spotlight).

It’s quite cute, and if you can read this, it means that I’ve been able to get it to post an entry to Status-Q. The posting facilities are fairly basic compared to a dedicated blogging tool, but I quite like some of its other features.

The real problem with using an electronic log book in place of a paper one, for me, is that I think it’s very rude to be typing and looking at a screen while somebody else is talking. Maybe society will get over this in time (or I will). And it’s well-nigh impossible to record anything while talking on the phone unless you have a headset or good speakerphone.

Anyway, in situations where keyboards are appropriate, MacJournal looks good as an option. It does seem to have lots of happy customers.

[untitled]

I've just downloaded the latest build of OpenOffice.org, the Open Source package that used to be StarOffice, and I'm thoroughly impressed. The quality of the software was always pretty good, but they've made important changes in the way users interact with it.

First, they've got rid of the most-hated feature in StarOffice: its attempt to provide a whole new desktop, including a Start menu, within a window on your regular desktop. Each document is now a separate window, as it should be. I knew they'd have to drop the Start menu when they started porting it to MacOS X. It would have been too ridiculous.

Secondly, they've removed two big features, which makes a wonderful change in this world of ever-increasing feature bloat. The web browser and email reader weren't bad at all, but they were never going to be my browser and emailer of choice. There are good alternatives available, and abandoning these components concentrates effort on the more important parts. I certainly won't mourn their departure.

The third very good decision was to switch to XML as the file format. Each document is actually a ZIPped set of files and directories - the contents are in contents.xml, the styles in styles.xml etc. If your document has embedded images, they will be in a Pictures subdirectory within the ZIP archive. This has to be the Right Way to do it. If something is broken, you can open the document with WinZip and fix things yourself with a text editor. I've done it. I changed the style of some text. I tweaked some colours, sizes, and positioning of items in a drawing. I then saved the files and closed WinZip, and reopened them in the word-processor and carried on. Try doing that with Word. Manipulation by other software, and conversion to and from other formats, should be very straightforward.

So, for the big question. Would I actually use it myself in preference to Microsoft Office? Well, I'm very tempted. There are still a few rough edges, and there is no 'Help' documentation yet, but the conversion filters are good, and the underlying philosphies are so sound that there aren't many reasons not to switch. I can also run it on all the operating systems I use.

But if you are interchanging data frequently with Microsoft users, then however good the alternative, it won't be as convenient as if you used Microsoft. If you're to switch, you need incentives which make it worth the inconvenience. And the problem is that most users of Office don't pay for it. It is provided by their employer. Otherwise, I think, the £350 price of Office would now be sufficient incentive for most people.

[untitled]

Tom Bradford's 'The Future of XML' is a timely warning. Perhaps the motto for the W3C should be one of my favourite quotes, taken from Antoine de Saint-Exupery:

You know you have reached perfection in design, not when there is nothing more to add, but when there is nothing more to be taken away.

[untitled]

There is a quote from Byte at the top of the XML-RPC home page:

"Does distributed computing have to be any harder than this? I don't think so."

No, it doesn't have to be, in many cases. I've just been making my first real use of XML-RPC, and it was perfectly adequate for my needs, trivial to install (at least for Python) and to debug. It's also very easy to learn, especially if you understand XML; the entire spec is just a couple of pages, written in a very laid-back Dave Winer-ish 'this bit isn't defined, it's application/implementation-dependent' style which would probably make writers of most other technical specifications begrudge it the name.

The big question, then, is what the other systems like SOAP, Java RMI, and more particularly CORBA, give you that make them worth the steeper learning curve, the installation hassles, and the devotion of large areas of bookshelf to 'real' specifications.

Well, you get performance, for one thing. It would be hard to define a less efficient method of sending certain types of data around than encoding them as a structured text document and using a general purpose parser to decode them at the other end. But unless speed is an absolute requirement for you, other factors are likely to be more important. Ever written a shell script, a Perl program, a Java application when you could have used C? Precisely. Developer time is more expensive than processing power.

But with many of these other systems you also get a raft of services that XML-RPC doesn't try to provide. Callback mechanisms, interface discovery, security, naming services, to mention a few. You also get a more thoroughly-defined agreement between server and client as to what the nature of the interaction is going to be. All these things add complexity, which is what makes other RPC systems more difficult to learn, but it's complexity you may have to implement yourself if you're building substantial mission-critical systems based on XML-RPC.

So the XML-RPC premise is that most distributed systems aren't like that. That the required interactions are typically simple things and don't need the complexity that something like CORBA can bring to your development. That the relatively slow speed of the internet or of user interaction makes the speed of the RPC system irrelevant. For the sort of stuff I'm doing, this is usually true, which is good because it means I can spend less time worrying about the plumbing.

So, should you use XML-RPC? I guess the answer is 'application/implementation-dependent'...