Russell Beattie

Okay, so it took me a day to grok what Jeremy was ranting about yesterday with his RSS-Data idea, but I think I've got the idea now and it's pretty damn neat. He's proposing to embed XML-RPC type data structures into RSS, and at first I was pretty doubtful, as this in my mind is what namespaces are for. We were just talking about this the other day for the calendaring info - creating a new namespace that contains the definition of the date and time elements, then include those elements along with your RSS for scheduling, etc. Why would you want to lose that sort of structure with a bunch of free-form data embedded along with your items?

But then I started trying to grok what the core of the idea was and I think I've got it. XML-RPC itself is simply method calls via the internet using XML as the data transport. You don't really need to even think about XML in order to use XML-RPC with most libraries, all the serialization/deserialization happens under the covers. You just say, "Hey, I want to call method named "doX()", on this server, with this data. What do I get in return?" For example, you could call the getCurrentWeather(String cityName) method on the myweatherinfo.com website, and in return get a bunch of text with the weather for that city. Pretty basic.

Okay, now turn this around. Now what happens is instead of having a server that's waiting for method calls via a push, your client sits and *pulls* the method calls via RSS. You can have a local method called addAlarmToCalendar(Datetime date) among others, then listen to an RSS feed for updates. When an RSS item has that method call embedded into its XML, when your aggregator sees that item it will trigger the call and set an alarm locally for you. You could set up these types of events, triggers, and even "chain" methods - i.e. once my alarm method is called, I can then put write out the call into another RSS feed which will alert other clients, etc.

It's quite an interesting idea. If the format is kept as compatible as possible with XML-RPC, I should be able to strip out the call from RSS automatically and pass it to Apache's XML-RPC library (using Java of course) without having to mess with a thing. Method calls become like namespaces using the data becomes much more flexible. You could have multiple "plug-ins" into your aggregator which understand various calls as they are developed.

I'm IMing with Erik about this now and he points out that you don't need a formal method call, but just some sort of key that tells the client what to do with the data. I'm just thinking in methods because at some point I need to do something with the data as a programmer. Jeremy gives the example of a recipe feed with structs of ingredients. Fine - so that's not a classic method, but more of a SQL-type insert. Whatever- at some point I need to call addRecipeInfoToDB() in my code, so it's the same thing.

Interesting stuff. I hope other people can grok it as well so we can start playing.

-Russ

Later... Hmmm, on second look at Jeremy's posts today, he says that what he's talking about has nothing to do with XML-RPC as a messaging envelope. In other words, he's not talking about calling methods, but just transfering data inside an RSS document using a similar data serialization format that XML-RPC uses. The argument is simply that using this form of serialization is less of a headache than an additional namespace. Hmm... I'm not sure quite sure if I'm with that. It's a very API-centric way to look at the data-transfer problem, and I'm not sure if that's a good thing.

Oh well. Hey, at least it's not RDF, right? ;-D