Reflections on RPC

Last night I had an online chat with Scott about how well the web services space has developed. We've both been digging Flickr and their API.

Sparked by that chat, this morning on the way to my day job I was reflecting on what RPC is and how it has changed over time. I have a short list of technologies I've worked with:

Sockets (late 90's) - Ahhh...the trusty socket. Open a connection. Send data. Receive it. Do something. Kind of like two people chatting, two processes share a socket and chat about which method calls to invoke. My early projects used strait sockets to talk. It was tedious to build but it works and it was light.

DCOM (late 90's) – COM’s hidden promise was to allow calls across threads, processes, and networks boundaries. DCOM was the cross network piece. My ventures into DCOM obviously extended through my usage of COM. It was conceptually clean but I struggled with security issues and the heaviness in its nature.

XML and HTTP (2000ish) – Somehow I ended up on the XML bandwagon and found it to be a better way to add syntax to the socket idea. But this time around rather than writing socket listeners I moved up the chain to a web server. It’s still light if you excluded the weight of the web server. This is being used with today’s Ajax framework.

XML-RPC (2000ish) - Dave Winer and friends developed this VERY clean and simple way of doing the basic remote procedure call over the wire using XML. I still love this format for its simplicity and elegance.

SOAP (2001ish) - I remember reading about SOAP in Visual Basic Programmers Journal. I was sold on the extensibility of SOAP. It was still clean and simple. However something went wild and I couldn't hold on anymore. Something about WS-*.

REST (2002ish) - I liked the idea behind this. Working along side HTTP and XML you could setup an entity and use standard HTTP verbs to manipulate it. It’s a little different thinking than the RPC but kudos for the simplicity.

Over the years I've grown to love simple models based on simple standards. For most projects I would rely on XML-RPC and/or REST.

MidiWeb

Last week I saw a killer group play at a local hangout. Their set was entirely electronic with an array of 4 or 5 notebooks powering the live show. They used a variety of musical instruments to improvise over the arrangements. It was quite impressive.

The name of the group was Aspects of Physics. One of the members runs an interesting project that uses python to tie together midi and tcp/ip to coordinate live music arrangements and production. Notes from the project's website:

* Realtime music collaboration via the Internet through web pages

* The easy develpoment of unique interfaces for controlling devices aiding to the perpetuation of experimental music

* The common use of midi not only for music application but also for lighting, robotics and digitally controlled devices


Pretty cool stuff! Find out more at: http://www.midiweb.org