April 2005 - Posts

Fooling around with the Atom API

I've been familiarising myself a bit with Atom lately, developing some code to use the Atom API with Blogger (yeah I know it's been done and done well, but it's all about learning how things work).
My objective is to create a C# wrapper for the API, produce one or more simple Blogger clients that use it (this time I was thinking of maybe one each for Windows, Pocket PC and Smartphone 2003), and make the source available for download so people can use it to spark their own ideas and hopefully come up with something useful and pretty.
I'd ideally like to be able to target other Atom-powered tools such as TypePad and so on, although the diversity of implementations is daunting (not just authentication: even fundamental things such as whether embedded markup is escaped. It's fair to say that on most of these issues it's Blogger on one side, everybody else on the other).

So anyway, things have been steaming along quite nicely and I have PUT, POST, GET and DELETE methods all working (we're so lucky compared with our poor J2ME brethren).
However, one little glitch is driving me crackers: Every time I create a post, the <content> tag has an extra <div> added to it (in addition to but exactly identical to the one that I am putting there myself). This is both puzzling and very annoying.

For instance, here's what I send:

<content type="application/xhtml+xml">
<div xmlns="http://www.w3.org/1999/xhtml">Yet more fooling around with Atom. Actually, I've just spent my Sunday afternoon and evening at work, so I should probably give up for now and go to bed.</div>
</content>

And here's what comes back:

<content type="application/xhtml+xml" xml:base="http://kevindaly.blogspot.com" xml:space="preserve">
<div xmlns="http://www.w3.org/1999/xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Yet more fooling around with Atom. Actually, I've just spent my Sunday afternoon and evening at work, so I should probably give up for now and go to bed.</div></div>
</content>

It's a mystery to me.

Some thoughts on the passing of loose XAML

   Since installing the March 2005 Avalon and Indigo CTP I've been working through some of the stuff I'd already done, finding out what changes were necessary to get it running. Today for instance I updated the ThreatLevel (don't ask) demo I showed people at a recent user group meeting (in order to demonstrate data conversion on binding...I'm thinking of extending this to show how converters can be used to localise textual data from web services or similar sources [in other words provide local language substitutions for simple one-word responses], in which case I might post a piece about it here or elsewhere). I've decided however that I won't be updating the XAML version of my CV (it's not like it got me any job offers or anything), since the removal of loose XAML means that I would need to provide an executable to read it (given that it is no longer possible to have XAML docs opening themselves in IE) - and who in their right mind would run something like that? So it didn't really seem worth the effort for something that was after all a pretty daft idea in the first place.
Which brings me to my somewhat rhetorical confused musing: one of the reasons for removing the loose XAML option was apparently (according to a post I came across somewhere) to reduce the attack surface...oh yeah? So to reduce the attack surface we replace the option to host in IE a XAML document that has no ability to do anything at an application or system level (what I mean is it's just UI, for God's sake - no events, no embedded code, nothing except eye candy) with something that absolutely must be compiled (or be loaded from something else that was compiled) or it simply won't work...yep, that makes me feel safer already. Back to perfectly safe Let's-Try-That-.EXE-And-See-What-It-Does land. Oh well.

I know, I'm probably being naive and unduly snarky here and missing the big picture, but I have to say I'm a little bit perplexed as to exactly how this helps.

PS. It also makes at least one of the “How-To“s in the SDK a “How To Do Something Which Won't Actually Work“, which a casual observer might think was a bit of a waste of time, but I'm sure it's good for the soul.