Lately I’ve been working with remote procedure calls (RPC). My experience is that they tend to be more trouble than they are worth, but I thought I’d give it another look. RPC is a way to program in which you write a program as if it were run on one computer, but some of the commands are run on a remote computer.

At its most basic level, RPC is just message passing. You send the message “what is 2+2?” to a computer, and you get back the message “4.” In fact, message passing is all computer networking ever is. Message passing isn’t hard, it simply doesn’t look like normal programming. So RPC decorates message passing to look better. And when you are working with complicated data, it can make life easier.

The problem is that there seems to be an inevitable slippery slope of feature creep, which ends up making RPC unusable. The cycle seems to be:

1. Start with general-purpose network protocol du jour, sending messages from a client to a server.
2. That’s not enough like regular programming, so add wrappers to let you send arbitrary commands to the server.
3. Oh, and the server should be able to send commands back to the client.
4. But wait! That’s not secure! Add security protocols.
5. (Optional) We don’t want to be restricted to one programming language; make it multi-language.
6. How do we know what the server can do? Let’s add a directory for finding services. Better yet, let’s add a directory for finding all servers– and maybe a directory for finding other directories!
7. This is unusable. Let’s start over with the new general-purpose protocol du jour.

Case in point #1 CORBA. Before CORBA, you used specific protocols (FTP, SNMP, etc.) which could be coerced to trigger remote actions. Even today, you can unsubscribe from an email list by sending “unsubscribe” email to a particular address. If those weren’t good enough, you passed C structures (massaged to be network-safe) from a custom client to a custom server. Then CORBA came around, and over time it obtained all of the features listed above. To make it multi-language, the CORBA spec required you to name your commands commands so they looked funny in most languages but would work in every language. And most implementations were buggy and expensive. But the killer for CORBA was that it required ORBs (service directories) on specific ports, and those ports are blocked on firewalls by default. When I worked at Net Perceptions, we discovered that many of our customers couldn’t use our product because the IT department which controlled the firewall was five layers of management away.

The solution was to piggy-back on port 80, the web server port. That is, run RPC through a web server. Someone had recently written an article on how much easier RPC was if it was done as XML messages through a web server. And that’s exactly what we did. Worked like a charm.

Next thing you know, a committee was formed to standardize SOAP (Simple Object Access Protocol) for XML over RPC. Sun and Microsoft announced that Java and Windows would both support SOAP. Everyone joined the bandwagon. Pretty soon SOAP was just as unwieldy as CORBA. Talking to eBay from Java yields 700+ auto-generated classes!

The fact of the matter is that for most things you want to use RPC for you use (1) a server you write yourself talking to (2) a client you write yourself, with (3) a small set of commands, which are known in advance. Directory services are almost universally a boondoggle– yet they are nearly always a required part of the protocol. Multi-language support is rarely needed, and if you do need it, the easiest way to do it is through a simple, clear message protocol; RPC auto-translation of one language’s structures into another yields ugliness in both languages.

My prediction is that in the next iteration someone will discover that you can use AJAX for general-purpose RPC. The new protocol will use all the so-called Web 2.0 technologies, including RSS feeds. A committee will be called together to standardize mash-up-style RPC. JavaScript (ewww…) will be used for sending arbitrary commands hither and yon.

Side note:

I’ve just spent a week trying to coerce Java RMI (Remote Method Invocation) to do what I want. As RPC goes, it’s better than most. But there are a few special requests I need to make of it, each of which doubles the complexity. And now I’m at a pont where I’ll have to add a special security policy to the Java runtime, which just plain isn’t feasible for this project. I could do it, but it would make our web server far more fragile. That or spend another day or two learning the bowels of Java security. So I’m about to rip out all my new code and go back to a simple socket-based message passing protocol.

Over the years, there have been countless arguments and counter-arguments about Linux security versus MS Windows security. Those of us who have to deal with computer security know that Linux (and other Unix-based OSes) makes it possible to mantain a secure system, whereas Windows is encumbered with a rich legacy of bad design decisions. Unfortunately, there are enough knee-jerk partisans and opinion-for-hire analysts to keep the water perpetually muddy.

These charts show just how much more needlessly complex Windows is, and by extension, how much harder it is to secure. They also help to explain why Windows Vista missed its deadlines by several years. This is why Linux (and Mac OS X, which is similar) get cool new features year after year, whereas every major Windows version is a deadline-breaking fiasco.

The obvious rebuttal to the previous Struts/JSF post is: “If you’re so smart, why don’t you open source your solution and show the whole world your bright ideas?”

And perhaps I should. But open sourcing is significantly more work than just writing an in-house project. For one thing, you have to keep from having in-house dependencies. That part’s relatively easy. Harder is finalizing an API which is generic enough to be generally useful, but not overblown.
For example, I don’t have a use for mutli-lingual error messages, but you cut yourself off from most of the world if you have an English-only attitude. One of the annoying things about Struts is that it requires internationalization of everything– you can’t just give it text, it requires the name of a text field where it can look in a language-specific file.

The best way to get a good API is to start out with a minimally useful API, throw it out to a bunch of testers, and evolve it based on actual needs at a variety of places. Which means you need to get interest in it and foster a community of developers. And that takes time and effort and a willingness to toot one’s own horn.

At the same time, I’ve found myself reinventing the Struts wheel here and there. Particularly for error handling. Many of the design decisions they made were good. Still, I’ve written only a tiny amount of code, and it’s about as full-featured as I need. Much of the value in a good framework is in the design patterns it enforces; the code itself is rarely particularly clever.

I’m a big Mac fan. I’ve been into Macs since my dad bought the original 128K Mac. I regularly read Mac news sites, especially John Gruber’s excellent Daring Fireball. And yet, despite all the hype, I don’t see an iPhone in my future– even if the price comes down.

The fact of the matter is that I love my Treo. And I love it for many of the things that Apple is rejecting. It has great physical buttons; I can play Astraware Sudoku comfortably with one hand while holding a sleeping baby in the other hand– at times without looking at the screen. I have appointments in my calendar dating back to 1997 and recipes dating back nearly as far. If I really want to geek out, I can write little Lisp programs with it. And it plays a text adventure written by my friend Seebs. Last week I bought a Spanish dictionary for it. The iPhone, on the other hand, will only have limited capabilities to run third-party software. How limited, Apple won’t say.

The fact of the matter is that the cell phone market isn’t like the PC market or the pre-iPod music player market. Apple isn’t the only company in the world that does good design work. Apple has been able to excel by not making the sorts of mistakes that technology companies often make.

The main mistake is to think of features only. Features before function and features before fashion leads to features without fun. If getting to a feature is annoying or frustrating, people won’t use it. Apple’s signature is to simplify a design until it looks more like a slab of plastic or metal than a device with buttons. And they also like to shrink a device to unimaginable proportions.

In fact, that same design aesthetic is what launched the Palm Pilot. Apple’s own product, the Newton, was a technological tour-de-force with an incredibly sophisticated operating system. But it was slightly too big (the size of a paperback) and the handwriting recognition required legible handwriting. The Palm Pilot, like the original iPod, was lambasted by critics for being too limited. It had no printer port and rather than recognizing handwriting, it had a funny language for entering text. But it took over the handheld market because it was had a long bettery life, synchronized well with computers, felt good in one hand, and–most crucial– fit in a shirt pocket.

The cell phone market is one which trades in Apple’s strengths: highly integrated software and hardware, design that makes a fashion statement, and top-notch usability. Microsoft couldn’t penetrate the market for the longest time because they forgot what Nokia and Palm never do: that the phone must work flawlessly as a phone, first and foremost.

So why is it that, after Steve Job’s demo, everyone is complaining about how hard cell phones are to use? (Strangest to me is the claim that it’s too hard to insert phone numbers, since just about every cell phone will offer to add a number after every call, sometimes including the caller ID info.) Part of the answer is wishful thinking: typing on these things isn’t as nice as using a full-sized keyboard, and we can hope (despite early reports to the contrary) that Apple’s solution is better. And every new technology sounds better before you try it. But Apple does have an advantage that Palm and Nokia don’t. Integration.

One of the cool features of the iPhone is voice mail as a graphical application. That’s something that every cell phone could do and should do. And don’t think that the manufacturers haven’t thought of it. The problem is that they need buy-in from the cellular providers. And the cellular providers don’t care enough to handle the technical hurdles. From the demo, it’s not clear if the voice mail goes over the cell network, the messaging network, or the Internet. If it’s the Internet, you’re dead in the water if you don’t buy that additional service. I don’t have Internet service on my Treo, and I’m glad I don’t need it.

There are lots of chicken-and-egg issues in the cell phone business. Cell phone makers don’t want to sell to only one provider, so they don’t work with one provider to add special services. Meanwhile, providers in the US often disable features they don’t like. Apple, being a newcomer with a huge amount of clout, was able to cut a deal with Cingular to provide a phone with all sorts of integrated services.

A second issue, specific to Palm, is the Palm OS. Once it was a paragon of simplicity. Now it’s under-capable. Not just that, but Palm, trying to be the next Microsoft, split into a software company and a hardware company. Long story short, Palm (the hardware company) hasn’t always had control over Palm OS. And the latest phones need PC-style multitasking capabilities. Palm isn’t there yet. Manufacturers which use Linux are there. (If you strip away the desktop user interface, it takes a hard core geek to tell Mac OS from Linux. On a cell phone, Mac OS has no particular advantage.)

So the iPhone has two distinct advantages: no legacy, and tight integration with Cingular. In terms of making a cell phone with an easy-to-use and flashy interface, that’s a big advantage. But seeing as Verizon has better customer service and better coverage around here than Cingular, and seeing as I’m enjoying my ability to use my old Palm apps (and would hate to loose my recipes!) I’ll be sticking with Palm for the forseeable future.

I expect that the iPhone will shake up the industry in a good way. Expect to see graphical voice mail everywhere in a few years. I just hope Palm weathers the competition (which is not just from Apple right now) and comes back fighting.