JSON vs. XML for configuration files?

One of the topics we’re discussing in Thunderbird dev land involves how to distribute configuration files for Thunderbird, so that if you’re part of a group (users of large ISPs, enterprise users, gmail users, whatever), that the “right” default configuration can be picked up as automagically as possible.

There’s lots behind that effort, but there’s one point of debate which I thought I’d throw out here explicitly to get input from people outside the Thunderbird community. Thunderbird can easily support either an XML dialect, or JSON files. There’s a feeling that the formats are isomorphic, and that figuring out which syntax ends up being a tooling issue, in particular for unknown third parties who might want to also implement parsing of these files. Some people believe that XML, being more mature, is more likely to be parseable by various software packages “out there”. Others believe that JSON is a better fit, because it’s lighter weight, more mashable, etc.

Are there good best practices that people have developed as to when to use which markup language?

Comments here, please. Keep it civil and constructive, please!

Django, day 2

So far, Django is still quite nice. I had some configuration problems (it didn’t help that I was also trying to setup a new OS X box at the same time), but nothing that a little perseverance and the kind help of people on the #django channel couldn’t fix.

Django is still clearly evolving quickly (which I like), with some fascinating discussions on the mailing list as to the proper role for AJAX-style toolkits in a tool like Django. Django doesn’t (yet?) have the insane buzz that Ruby on Rails has, but the fact that I know Python (and the Python libraries) makes me feel like I will be productive much faster w/ Django than with Rails. I’ll probably poke at Rails periodically as well, to see how that’s evolving.

Other tools I had good interactions with today: subversion, trac. Apart from the fact that the Powerbook keyboards bboouunnnceee a lot on me, I’m having a Good Computer Day.

Django: ooh, shiny….

I’ve spent a few hours re-dunking my head in the Django soup. That is one impressive open source project. Apart from the immediately appealing superficial qualities (great name, beautiful CSS), it has truly stellar documentation, that shows (or at least seems to show!) that the people who designed it really knew what they were doing. A real pleasure. I’m looking forward to playing with it. It feels like opening up an iPod box and admiring the packaging, design, button layout. I just need to get some tunes onto it now!

Web 3.0?

In which I wax hypothetical on what comes after the Web 2.0 programming model.

Part of my job is to keep on top of trends, technology happenings, buzz, gossip, etc. It’s fun, and it’s made possible because so much of that is available on the net (I don’t need to learn golf), and much of it through RSS and related feeds (it’s all “in one place”).

As a result, I spend a lot of time in bloglines, my current aggregator of choice. As much as like bloglines, and am quite pleased with its sparse user interface, which keeps mostly out of my way, I find that I wish it were more efficient still. I’m puzzled to see that bloglines, as far as I can tell, hasn’t evolved its user interface since I started using it (months and months ago!). Compared to flickr’s evolution in the same time period, that’s like being “biologically stable”. Even gmail has evolved as many have noted recently (although less than I’d like).

My fantasy life includes finding the time to hack together a greasemonkey extension to enrich the keyboard shortcuts in gmail and add some to bloglines, to make using these tools as efficient as using a rich app. Coming from the world of “shipping software” , it’s frustrating to see that something as “80’s” as full (let alone customizable) keyboard shortcuts isn’t considered a baseline requirement for a high-end webapp in 2005 (I know Mozilla can hack it).

Then again, when I find out the lengths that people like Alex Russell have to go through to deal with the history mechanisms in modern browsers, maybe it’s not that surprising. Simple things are hard, and hard things are just way too hard.

I do hope that Alex and the Dojo folks (or others) succeed in building a popular, higher level abstraction for web 2.0/ajax apps, or it’ll just remain the province of a few privileged companies, which would be a shame, and is certainly not in line with Sir Tim’s view of what the Web should be. In my mind, success will have been achieved when it’s as easy to build an interactive web app as it was to build a HyperCard stack.

Part of me feels that what’s really needed (assuming we have the collective energy for it) is a truly new programming metaphor, that understands the implications of web architectures deeply, including the need to distribute computational tasks based on differing latencies, persistence capabilities, user interface requirements, data security constraints, and more. Here’s a fun thought experiment: what kind of programming language would you want in a Web 3.0 universe, assuming (please!) that you’re not stuck with JavaScript on the client, and that (please?) you could write one program, not one per web page on the client and one (or more) on the server? Wouldn’t it be nice?

You might want something like E4X, although that seems too shallow a shift (if it’s got a spec, it can’t be that much of a paradigm shift). You might want a language that thought about security and distributed systems from the start? Maybe it’d be something built on a small VM that you could reasonably see in enough key browsers? What mountains would have to move for such a scenario to pan out, I wonder…