Questionable efficiency

Is re-inventing the wheel the pinnacle of efficiency, that any new bee XMPP client developer absolutely insists on re-writing yet a new XMPP stack from scratch? Or is XMPP is really lacking an efficient approach at quickly creating new client based features, as Robert is explaining in his post. No need to tell you that I agree with his analysis and proposed direction. I would love to have an XMPP client development environment for me to experiment quickly with new ideas, without having to learn a new development language or to rewrite a client from scratch every time.

Today’s client development tools landscape lacks well defined and agreed upon API layers to abstract XMPP client development. Some commercial SDKs offer a better approach to this abstraction than open source projects. But even in their case, they use incompatible APIs, and they are usually limited to a single OS. Nevertheless, beyond the apparent differences, their APIs provide very similar functionalities. It would make sense to harmonize these APIs into a common set of definitions. After all, it maybe time for standardizing a little more than just the XMPP protocol.

This statement will probably create roars in the XMPP client developer community. There a very valid issues arising from trying to bring together all these islands of programming languages, OS silos, an strong opinioned personalities. I believe higher abstraction and common APIs is a necessary evolution when a technology is maturing. This is necessary to change what is perceived as a varied, but in this case very inefficient, XMPP world and help create a greater value building platform… Value comes from wide adoption, ease of extension, and quick time to implementation. Value resides in the thousands new usages of an API a programmer never thought of when it created the API in the first place. Value is in building applications to solve somebody’s pain points, or to offer new services to a community, not in building XMPP clients. This is what Robert’s post is about.: how to evolve from XMPP client building to XMPP application building?

As a proof that this is the right way to address the problem, let’s quickly look at the existing landscape. An entire ecosystem is in the making that leverage the RTC APIs available on any Windows workstation. The built in messenger service provides all what is necessary to any developer for creating real time communicating applications through this API. You may not like it because it is from Microsoft, but this is a fact. Apple did something similar with iChat. For the very simple reason these two companies want developers to create applications on their platform as opposed to building clients.

I would really like and benefit from an XMPP agent when experimenting with new client applications. It would be even more interesting if an agent based architecture was available for the major workstations operating systems. Properly engineered, it would provide an open alternative to proprietary stacks already in place for some of these OS. I would welcome an initiative along these lines fostered by the JSF…

Technorati Tags: XMPP, Jabber, Antecipate