---

I’m probably late on the wagon with this, but I just discovered that standardized protocol interfaces are fast becoming commonplace – and I’m not talking about the network-side interface, I’m talking about the application-side interfaces, also known as APIs, or should I say open APIs.

APIs used to be a matter of taste and design, pride and prestige; they were known to make or break an SDK. All this is about to change, as APIs are being standardized, and SDKs from different vendors will be interchangeable as your network card or USB mouse. Add to this the low cost of general-purpose processing units (GPPs) and you will understand why software is taking over traditional hardware roles (think about washing machines and cars).

Am I taking this too far? I may be late, as I said, but I’m afraid I’m dead on target.

Wikipedia Ride

First, a little disambiguation: web 2.0 has been with us for a while, with its service description language, remote procedure calls, Open APIs, you name it (and I’m not linking to the Wikipedia definition of these. If you don’t know any, just Google it up). I’m not talking about these. I’m not talking about network communications at all.

I’m talking about good old software libraries. I’m talking about a very specific form of Service-oriented architecture. I’m talking about Component-based software engineering and Modular programming, but not quite. I’m talking about a form of the old COM, KPart and Bonobo. I’m talking about, ladies and gents, what OKI, OpenInterface and many others are trying to do as I write these very lines: full encapsulation, reusability and interchangeability of any software component.

We’re still not there, of course, but it’s completely within reach. Look at how hardware is getting along just fine with the “plug-and-play” concept. I could go to any store, pick up any hardware, plug it into any computer, install a driver (which the OS does automatically for me in most cases), and in 99% of the time it will work like a charm. So why isn’t software like that, apart from (aforementioned) sporadic examples? It is all for the lack of one, agreed, open, standardized, application-programming interface.

We VoIP developers are used to having a standard under us, but will we adapt that easily to having a standard above us, in our connection to the application?

VoIP Industry Implications

Let’s pretend for a moment that we have such a standard. Answer these questions, please:

• Standardized or Proprietary?
• SIP or H.323?
• In-house or outsourced?
• Open Source or Commercial?

The answers are, by order: both, both, both and both.

Why would you settle for anything else? Especially if you can develop over the very same interface, first a proprietary proof of concept, then some basic SIP you whipped up, adding an open source H.323 when you branch out to the enterprise market, and replacing them all with a commercial implementation when your company grows. And when a new protocol arrives, you will just add that below your existing code.

A unified API may seem unreasonable when you consider that each service provider has its own set of requirements and limitations. I think that it is unreasonable, economically, to think that this can continue for long. Sure, there are advantages and specifics for each protocol type and implementation variant, but for mainstream make-a-call scenarios, a unified API is feasible. There will be some pushing and pulling between different power groups until the standardized API will be stable, and there will be some gaping holes allowing non-standard operation, but we’re used to that from the network protocols standards. Moreover, protocols learn from and imitate each other, so a novel functionality in one is likely to be mimicked in another. The developers of protocols will have to design protocol stacks that will be adaptive to many environments, perhaps specialized flavors of their toolkits to different environment.

It’s hard to guess the effect this will have on the industry. It will require more extensive testing, and some rethinking of the design, especially error handling. It will probably push the whole “strict protocols” thing straight out the widow. I expect script protocols to become big, since they solve many issues of implementation variants. I think system security will be better, but it would require more maturity on the part of users.

Eventually, I think every user (and his mother) will become a part-time system integrator, selecting between components on the fly. It will be like installing a mouse, keyboard or mp3-player*. If one SDK doesn’t work, the user will replace it with another that does. SDKs will eventually become a consumer product, part of the whole ecosystem of service mash-ups (and yes, I do believe service mash-ups won’t be just for know-it-all geeks very soon).

Whoever plays best with others will probably win.

---

* As a matter of fact, I think the main difference between inserting a USB device and connecting a card to the motherboard is the user-friendly plastic in the former and the use of a screwdriver in the latter. For some reason, people associate screwdrivers with technical expertise.