November 7th's delayed post

[torkell]

Today's post will have to wait until tomorrow later today: it's taking me longer than I was expecting to knock up a python script as part of the post.

Python scripts should be nice and quick to create. Unfortuantly this does not seem to hold when you add XML into the equation.

Comments

[pteppic.livejournal.com]

I have yet to find anything other than Linq that makes light work of XML... It's a bloated technology by definition.

I tend to try and stick to JSON now if I'm having to throw light objects around between client->server.

[torkell]

I did find something called ElementTree, which was a lot easier and more intuitive than the DOM. The downside to it is that it keeps the entire structure in memory, so it's only really usable on small XML files. Works well enough with an Atom feed though.

I've seen JSON in use, and to me it looks, as with all good hacks, like an horrendous abuse of Javascript. Looks like it's got nice potential for security holes as well, if anyone's foolish enough to eval() it server-side without filtering it.

[pteppic.livejournal.com]

JSON's key advantages are it's simple and light. It's noting more really than an associative array passed as a string. Since your server normally isn't running Javascript, passing it a JSON Object is harmless when common sense is applied. Security at ther client *can* be a concern, yes you can use eval(), but best practice says to use the JSON parser, which throws a hissy fit on your behalf if you're doing something you shouldn't be.

It's also got fuck-all overhead, so if you're passing between client and server, you're not sending whopping chunks of data over the pipe.

It's a tool like any other. It has it's advantgaes and disavantages.