Hookflash JavaScript API for Cordova / Phonegap on iOS

Today we are happy to announce availability of Hookflash for Cordova / PhoneGap (alpha).

Hookflash for Cordova - iOSNow Cordova / Phonegap developers can leverage the new Hookflash JS API via Open Peer Cordova Plugin to create RTC (Real-time Communications) applications for iOS quickly and easily.

Social identity & custom identity models are supported. Use our OAUTH API to integrate your own identity model.


Use HTML5 and JavaScript to add messaging, voice and video to existing Phonegap iOS applications, or build something new!


Free developer account, no credit card required, sign up here. The Cordova plugin can now be found in the Cordova plugin registry here.  The plugin source is available on Github.


When will WebRTC be ready for prime time?

No matter what camp you are in, pro-SDP or Object API, WebRTC feels like it’s here to stay. The fact that there is so much push-back on an Object-centric API in the WebRTC working groups tells us that there are many who are concerned about delaying v1 any longer than is necessary, there is a feeling of urgency, which seems like a good thing.

As an application developer, one looks at the current state of WebRTC as a proposed standard and it soon becomes apparent that it is not trivial. Building a commercially viable application or service will take much more than a few JavaScript APIs leveraging the WebRTC stack in Chrome and Firefox.

WebRTC is in its early infancy, building a commercial service using WebRTC in the browser today is not only unlikely it might even be a little silly. That’s not to say that the work being done in and around WebRTC today isn’t valid, far from it. It’s just that WebRTC “in browsers” is far from being ready for any service to deploy commercially and scale.

Where are we most likely to see traction early on?

What WebRTC, or specifically Google, has given us is a great media stack that we can leverage in apps.

Mobile is where WebRTC can be put to work easily and quickly. Any iOS, android or even BB10 application developer can now make use of new mobile developer toolkits that include the WebRTC media stack plus other features like social identity federation, p2p signaling and the like. Mobile is where WebRTC technology shines today.

Building for mobile first is not just convenient it’s smart. By building on mobile ahead of the browsers the developer somewhat “future proofs” the life cycle of the product being developed. When WebRTC is ready for prime time, those mobile developers will be in a perfect position to deploy to the browser, potentially edging out their competition.

When will the browsers be ready?

It’s going to be the better part of a year (some say years) before some of the hard problems are solved in the respective WebRTC working groups and even then the v1 features supported will be somewhat minimal. Even I thought this would have been done by now, but we are a long way from done.

Questions remain unanswered:  Where is Apple? What will Microsoft do with CU-RTC-Web?  What video codec will be chosen as MTI?

Regardless of how much work there is left to do, the bureaucracy and politics inherent in the standards bodies will ensure that we will not see this in production across all major browsers anytime soon.

As an example, let’s take a look at XMPP. Before it became a standard XMPP was the Jabber protocol, an open technology used primarily for instant messaging and presence. Since Jabber was already defined and deployed heavily all across the globe you would think the standardization would go rather quickly, right? Nope. That process took more than 2 years in the IETF and very little was changed.

If you are a mobile developer looking to leverage WebRTC for a mobile project, you’re in luck! There are some good mobile SDKs available today.  You might want to hold off on deployment plans for all the major browsers anytime soon, especially not if you are focusing your efforts in the Enterprise markets where MS Windows and Internet Explorer still rule the roost.

Now Hiring: Mid-Senior NodeJS / JavaScript Developer

We are looking for an experienced JavaScript developer to join our distributed team working on our open and closed source projects.

The successful candidate has proven experience working with NodeJS and networking multiple NodeJS servers to work together as a whole.  You will live somewhere in North America.

This position will require someone who can actively participate in implementing version 2 of our stack and become a core member of the team.  If building a system that will auto-scale to millions of users and be completely fault tolerant peek your interest, this position is for you.

Hookflash speaking at jQuery Portland – building video chat for the web

Robin Raymond – Chief Architect, Hookflash –  will be speaking at jQuery Portland on June 13. Robin will be building a P2P (peer-to-peer) web-based video chat application with jQuery, using elements from Open Peer & WebRTC.

Open Peer now in JSON

The newest Open Peer Protocol Specification has had a significant revamp, which we are all excited about here at Hookflash’s headquarters. The protocol has become “JSON-ified”, if that can be made into a verb.

The original specification was written using an XML as that was the technology easiest to integrate into the original C++ implementation at the time but it had outgrown its usefulness.

What does this change mean in practical terms? Anyone using an end product built upon either protocol might not have noticed any difference but there is a few important aspects of JSON that make it better suited for Open Peer and as a web technology under the hood.

XML is a powerful document markup language, including a document description language whereas JSON is really a data exchange format. JSON is much simpler. It’s the complexities of XML that actually make it harder to handle. Using XML required every engine to have a minimum powerful XML functions to wield the protocol. JSON’s simplicity makes the implementation and exchange of data much easier.

This allows developers to concentrate on what they actually need to do – exchange information and data and not spend time worrying about XML and all the strange yet wonderful magical things it’s capable of doing, but with little added real world value aside from a few specialized situations.

JSON’s ease of use is exactly the reason why JSON has exploded in use in the JavaScript world of the web. JSON converts almost directly into easy to handle programming language structures and in the case of JavaScript, it’s a 1-for-1 mapping to the language. This makes implementing with JavaScript as simple as handling normal data structures, and is a great sequa to OPJS our Open Peer JavasScript library.

Easy programming = better and more sophisticated applications.

Then there’s the “cool” factor. Communications protocols throughout history have been mapped onto the prominent paradigm technologies of the time. H.323 was based on Q.931 ISDN telecommunications. SIP was based on HTTP header processing. XMPP was based on XML. Now finally a communications signaling protocol that mirrors today’s adopted open web standards – JSON.

Still prefer XML? Well, you can still use it. The format of Open Peer was specifically designed to allow easy JSON to XML and vice-versa. Use whatever processing you wish if the need is truly there. But I have to ask, why would you want to?

Please take a glance at the latest version of the Open Peer Protocol Specification.