Mark Pilgrim has written a fairly technical yet easy to read article on how the Atom Authentication protocol works.  They have chosen to base the procol on the Web Services Security UsernameToken Profile which is, while not finalized, a reasonably secure authentication protpcol.

I think they made a good choice — it's kinda ironic that Atom API, which is based on REST, is leveraging an ongoing work to secure SOAP-based APIs — and would like to see the procol implemented for XML-RPC-based Blog APIs as well.

Only problem is that it places a burden on the client to calculate SHA1.  Yes, there are JavaScript implementations of SHA1 and they are fairly fast, but you will still need either JavaScript or Java VM on the browser.  And then there are mobile devices which are still behind the curve on the computing power.  Oh, well.  It's difficult to find a universal solution anyway.

BTW, using just plain username and password is just fine for most blogs IMHO.  This stuff is mainly for corporate users posting to internal blogs, yet-to-emerge infrastructure blogs upon which many people depend on to receive critical information in timely fashion, and trusted blogs like those featuring press releases (coming real soon I hear).  Just be sure to backup your blog content though just in case someone gets pissed off at what you write and decide to paint your blog red.

Certain design patterns are more compelling than others.  Some patterns are outright mesmerizing.  For example, the Hierarchy by Containment (also known by many other names) pattern,  which represents hierarchical relationships by have one object contain another, is probably the most popular XML schema design pattern.  Here is an example from XAML:

 <Window ID="root">
  <Button>Hello World</Button>
 </Window>

Since <Button> element is inside <Window> element, the button is semantically within the window.  This is nice because syntatic structure matches semantic structure.  Here is an alternate solution that XML designs often overlook:

 <XAML>
  <Window ID="root">
   <Window.Background>Blue</Window.Background>
  </Window>
  <Button ID="mybtn">Hello World</Button>
  <Insert object="btn" into="root"/>
  <Center object="btn" to="root"/>
  <Move object="btn" x="10" y="20"/>
 </XAML>

In the first approach, object properties and contents are specified together.  In fact, there is no real distinction between object properties and contents.  If there is a need to distinguish the two, syntax has to be changed by introducing a separator or a container like <Content>.  Problem gets worse when new a new aspect needs to be added.

In the second approach, contents and operations are separated from objects.  Admittedly, this approach is less visually appealing.  However the syntax is simpler to process because the unit of processing is clearly defined: immediate children of the document element.

BTW, I am not advocating one design pattern over another.  I just thought it might be helpful for people to see alternative approaches to designing XML data.

Despite some doubts about the usefulness of Jason Shellen's proposal for beautifying feeds with CSS stylesheets, I like it (choice #3 to be precise).  Can someone pull together a stylesheet for RSS 2.0 so we can do a taste test?

As to the problem of making it easier for news aggregator users to subscribe, aggregators will have to ship with a browser plug-in or do it like Radio does via a well-known port and URL.

I have examined quite a number of open source Java and .NET projects recently and there is a striking contrast between the two groups which is that Java projects tend to be over-architected and .NET projects tends to be under-architected.  In more mundane terms, it's the contrast between having too many joints and too few joints.  I am not talking about the kind that you strike a match to, but the kind that adds flexibility.  For Java, I think it might be a withdrawl from design pattern addiction.  For .NET, it's probably apply duct-tape til it works syndrome encouraged by Visual Studio .NET.

There is also a disturbing trend of hiding or scattering information from developers so that it is difficult to sit down and review several pages of code without having to run around looking for the hidden pieces.  For example, .NET introduced attributes which are like extensible metadata for pieces of code.  These attributes are very useful but they also hide details necessary to get the complete picture.  Another example is .NET's boxing and unboxing behind-your-back trick which, while well-intended and neat, often means disappointingly slow code.  After a few sessions of trying to get some decent performance out of .NET, I am already starting to see boxes in my sleep.

I had my doubts, but the URL spoofing bug in IE that Microsoft is supposedly investigating is really there.  The link-happy blogosphere, filled with copy-and-paste addicts, is a ready victim to this bugger (via Zap The Dingbat).

Test Exploit

The bug is caused by simply inserting '%01' in front of '@' character in URLs like foobar@blahblah.com to hide the real domain name from the fake one which goes in front of the '%01' (see the HTML source for this post).

As an architect, this sort of bugs takes a lot of energy out of me.  Ever feel betrayed by the ground you walk on?  It's like discovering that everything you designed was built on a gigantic turtle that just woke up.  I have obviously exaggerated the size of the problem but this sort of bullshit just upsets my stomach.

Another thing that upsets my stomach is getting all excited enough about something to invest months into it just to wake up and realize that there is no reason for people to use it.  There is a quite a bit of that in the web services and Atom hypes.  Get in the habit of asking Why Would They? if you can't take the disappointments.  IT is NOT about YOU, but ALL about THEM, the people who will be using what you build.

Update:

On my IE 6 running on XP with all the latest patches, this is what I see after pressing the "Test Exploit" button.

Examples of rough edges in .NET I pointed out are removed in the next version of .NET framework (aka Whidbey).  It will come with concrete classes that reduces provider-specific dependencies.

Don't expect magic though.  Provider-specific SQL syntaxes are not going away anytime soon.  While storing SQL statements in external configuration files is the obvious solution, there are associated security risks.  Digitally signed configuration files offers some protection, but it's a hassle to implement and takes away much of the power of configuration files.

I am looking at System.DirectoryServices namespace right now.  It looks to be equivalent of Java's JNDI package.  I am not yet sure how it handles in-memory objects (i.e. data sources) bound to the directory service.  Still moving.

Looking around the .NET Framework, I am impressed by what is there already and the amount of effort need to build such a framework.  Great deal of .NET is familiar because its design has been influenced by and stolen from Java.  There is no shame in stealing good designs IMHO.  There are some innovations as well which I am sure Sun will return the favor with by incorporating into Java.  If innovation is the butter of technology, mimicking is the bread.

However, there are some curious holes in .NET like the System.Data classes which I feels is superior to JDBC in some respect yet lacks built-in data provider abstraction classes.  To use a data source, one has to instantiate data provider specific classes like SqlConnection, OdbcConnection, or OracleConnection.

While one could write their own abstraction layer, most .NET programs I have seen chose to be hardwired to specific data provider implementation (typically Microsoft SQL Server).  Given that huge amount of design efforts went into .NET, it's a complete mystery to me why they ignored this obvious shortcoming.

BTW, if you want to avoid hardwiring your program to specific data providers, you might want to look at Brian Ritchie's data provider abstraction layer which he contributed to the Mono project.  I would have designed it a little differently and went a little further like abstracting data provider specific exception classes, but it's good enough to get you started.