Matthew Trump's Radio Weblog

Thursday, March 14, 2002

RSS-RPC Dave's idea of using RSS 0.92 as a possible way of expanding on the Blogger API to include such features on titles and links seems to me to a very natural progression.

The idea, I am thinking, would be to think of RSS not simply as a syndication document of content, but as a vehicle for RPC communication. In this scenario, the channel element becomes a weblog, and the item elements are new posts. The cloud element becomes a pointer to something like weblogs.com.

RSS could serve double-duty here, of course. You would still have an RSS document that provides a syndication of the current posts. What you are adding are one-shot RPC calls with (usually) single-item RSS documents that wrap new posts.

As Dave mentioned, the XML-RPC version would require a variable-sized struct with well-defined mapping of what each element means. In the SOAP version, things would be very straightforward. If you were going for the cheapest solution, you might wrap the the root <rss> element inside a SOAP envelope like this:

<SOAP:Envelope ... >
  <SOAP:Body ... >
     <rss>
        <!-- a channel corresponds to a particular blog -- >
        <channel>
           <!-- new post -->
           <item>


           </item>
        </channel>
     </rss>
  </SOAP:Body>
</SOAP:Envelope>

You can see there's a little bit of cumbersome overhead here. For the rss-rpc model, in the most cases, the only information you need to know about the channel is a unique identifier. The other elements could be specified only if they needed to be updated (i.e., you would include the <title> element of the channel itself only if you wanted to change your blog's title, likewise the link).

On the other hand, the subelements of <item> really begin to shine as blog post elements here.

It's not that RSS 0.92 is, out-of-the-box, a perfect fit for this model. It's just that it looks nice on a first approximation, and it is already well-known by many developers. The learning curve would be very nice. Also any deficiencies could be easily cleared up in the next release of spec. 12:12:35 PM

Call me crazy, but I do all my XML parsing with SAX. SAX parsing comes very natural to me. Although I use XML at almost every turn of every application I code, I have never used DOM, except to try it out, and I hope never to use in development. I don't have anything against DOM, per se. It's just that once you get the hang of SAX parsing, and develop some standard tricks for parsing what you want, there's extremely little reason to ever use DOM, in my opinion.

You can tell the difference between those prefer SAX and those who prefer DOM by the XML they design. SAX afficianados usually create XML with lots of attributes. DOM fans tend to prefer only nested elements. This is because in SAX, parsing attributes and attaching them to element names is very quick and easy, whereas in DOM, attributes are sort of an unnecessary complication.

Last year I read a comment about XML usage along the lines of: "good practice dictates to use only elements and avoid attributes at all costs." Whoever wrote this must have been a DOM programmer.

I don't mind people saying this, so long as it's stated as an opinion. The workplaces drones hear stuff like this and don't realize that it's just one person's view. Show me where it says in the XML specs that attributes aren't just as much a part of XML as elements?

Imagine HTML without attributes, only nested elements. Yikes! 10:28:58 AM

Another aspect of the web service I was working on is that I wanted to deploy a set of Java SOAP tools that I had developed. They are basically tools for creating "handrolled" web services.

I've discovered that I don't like using web services tools that hide all the serialization from me. I like seeing the messages. I like parsing them and composing them in buffers. I think it's because I'm a control freak at heart. 10:11:31 AM