Extending Ourselves (And JIL Unite’d)
Winter is coming to Norway (and Poland and Sweden, but allegedly finishing in Melbourne). Although the long darkness apparently means there is little else to do, we have also been busy over the summer.
As well as updated Server Sent Events and implementing Web Sockets we've made some other big steps in Core. The biggest news, of course, is extensions, but there's more to customisation than downloading an extension:
We will be publishing some more detailed information on the extension framework here very soon. But while you're waiting, a little more info on extensions, and a couple of other ways we have extended the platform since summer. ...
One of the most common requests we have for Opera is to add an extension framework. Opera is a highly customisable browser, and natively includes function that other browsers offer through popular extensions, such as Dragonfly (the debugging tool for local or remote device debugging), the content blocker, mouse gestures, and many more. We continue to build tools to help people be more productive. But we have also spent a long time looking at how to make a more powerful secure extension framework which doesn't impact performance too much, to allow for the very long tail of user requirements and desires. After this week's press announcement and extensions demos, everyone is eagerly watching labs.opera.com to see when the first release appears.
We have been testing with some extension developers and Opera community members, who have provided valuable feedback to help ensure that our first alpha has been road-tested. We will soon release an early version (and therefore subject to change) with documentation, but we expect the basics to be reasonably stable.
As well as adding buttons to the User Interface, we've been making the entire platform more powerful. Traditionally, Web applications could only interact with the Web - for security reasons they were not allowed to interact with the device they were on in many interesting ways. This meant that any significant amount of data had to be stored "in the cloud", instead of, for example, using your own address book.
Opera has a long history of working to change this, and combine the power of plugins and native applications with the ease of development and portability of Web applications. Opera Platform, first publicly available in 2005 on desktop and mobiles, enabled access to features such as the camera, address book, and location. In those far-off days when it was the only Ajax-capable mobile browser, Opera Mini was yet to launch, the iPhone was just an idea getting a certain Californian hot under the turtle-neck and even Nokia's mobile browser was unknown, this seemed like a step too far. Why would you want geolocation in a Web App? When we released the FileI/O API, enabling widgets to read and write to the file system instead of relying on the cloud to store all your data, the reactions were similar. But times have changed...
JIL is one of several different initiatives to enable Web applications (often built on Widgets) to use device functionality. Because it was initially developed by a consortium of Telecommunications carriers, it is primarily oriented to things related to telephones. Enabling your application to find out if you are paying roaming rates, making the device vibrate, sending SMS messages or receiving them and acting on them are all primarily telephone functions. But other APIs such as accessing the camera (e.g. to include a video stream in a page), sending an email, and reading or writing to the local file system (yes, they copied the original Opera File I/O spec as part of their development) instead of using expensive data transfers to the cloud are all relevant far beyond telephone devices.
The W3C's Device API Group is working on global and high-quality standards for many of these features, and we are contributing to the group and expect to implement their specifications. W3C geolocation has already been widely implemented (not just by Opera). In the meantime, we have implemented JIL "gold" in Core. This allows early testing and feedback that has been important in understanding how to raise the quality of JIL specifications (200 page PDF), and provides important field testing that help the W3C specs avoid making basic mistakes. At the same time, it allows developers to get familiar with the ideas, and some basic APIs that point the way towards the Web of the future, moving from native app programming to the huge cross-device and cross-platform market that the Web offers.
Some of the most interesting applications for Opera Unite are primarily oriented at the developer community. Want to control the geolocation data you send out? Your friends might not care, but you can do it with the geolocation provider application. Or you could develop on the idea and build your own geo-database. Want to be your own OpenID provider? Why not do it from your browser? Want to work on your code when you're not at your computer? Why not have a private Web interface?
But what about controlling your own space-rover car from your browser? (Or more prosaically perhaps, controlling your television from your mobile phone). Opera's Device SDK and CDK are built on the same Opera Core shared across all Opera products. So we're moving Opera Unite from the Desktop into the Core. This will allow you to run an application on your TV (or phone, or spaceship), and easily interact with it from anything with a browser (and to us at Opera, that means more or less everything, of course).