tola - open_standards

Keeping Web Apps Open

tola — Mon, 10 Oct 2011 17:09:34 +0100

Reposted from webian.org

The Universal App Platform

The best thing about web apps is that they can run on any platform. This is because they use a set of open standards which are universally supported. The latest incarnations of these standards like HTML5 and CSS3 are more powerful than ever and it seems inevitable to me that the web will eventually win out as the open, universal app platform.

The current generation of popular desktop operating systems like Windows 7, OS X and Linux and mobile operating systems like iOS, Android and Windows Phone treat web apps as second class citizens, inferior to their native platform-specific counterparts. But that's all set to change.

Microsoft Windows 8, Google Chrome OS, The Linux Foundation's Tizen and Mozilla B2G will all join Webian in putting web apps centre stage, as the preferred category of app on their respective platforms.

Fragmentation

Thanks to HTML5 and related standards web apps are already pretty powerful, but there is still some way to go before web apps can do everything that native apps can do. On mobile platforms new APIs are needed for access to telephony, messaging and cameras for example, and some kind of "app store" style distribution and installation mechanism is likely to be needed to provide a more app-like experience. "Installing" a web app is a little like bookmarking a web site and can provide an opportunity for the app to ask the user for all the permissions it needs up-front, download any resources which will be needed for offline use and perhaps add an shortcut icon to an app list.

Because there aren't currently established standards for all of these features, each platform is intially rolling its own approach. Apps for Chrome OS can only be found via Google's own "Chrome Web Store", you have to have a Google Account to install them and many of the apps found there will only work in Chrome. Windows 8 will have a set of APIs for its new Metro user interface, but apps written for Metro won't necessarily work on other platforms. We don't yet know much about Tizen, but previous mobile platforms like HP's WebOS and the MeeGo Web Runtime have also had platform-specific APIs.

An Open Approach

Mozilla is also working on a new set of web APIs, but in line with their mission of promoting openness on the web they're doing so in a more open way. You can see the progress of their APIs for telephony, messaging (SMS), battery, visibility, settings, power management and contacts on Bugzilla. These new APIs on Mozilla's core platform are the first step towards a new mobile OS from Mozilla called B2G or "Boot to Gecko". B2G will have a highly customisable UI built entirely with web technologies and will allow for the installation of Open Web Apps, as proposed by Mozilla Labs. With Open Web Apps, anyone can run their own app store or directory and the aim is to create cross-platform installable web apps.

Mozilla is also collaborating with Google on "Web Activities" or "Web Intents" which could provide a standard mechanism for apps to call other apps for certain functions. This collaboration is a promising sign because Mozilla can not define standards on their own and will need to co-operate with other browser & OS vendors.

Towards Standards

There are already standardisation efforts in this area at the W3C such as the Device APIs Working Group and the Widget Packaging and XML Configuration recommendation, but W3C recommendations are not always in line with what the implementors (browser & OS vendors) are doing.

For example, W3C Widgets provide a mechanism for installing a "widget" locally on a device by packaging up all of its resources in a zip file, including an XML manifest file. The specification was used for widgets in the Opera browser but when the MeeGo Web Runtime tried to use it as a method of installing fully fledged web apps it didn't work out very well.

Mozilla and Google are taking a different approach to installable web apps, both choosing to use a JSON manifest file and rely to a large extent on HTML5's offline capabilities for caching and updating offline resources. Even these two similar implementations have subtle differences which make them incompatible with each other so there's a real need for standardisation in this area if we're to have cross-platform installable web apps.

Hosted vs. Packaged

One slightly odd trend in the standardisation of "web apps" is the tendency to focus on "packaging" apps rather than "hosting" them. This seems to be an attempt to emulate the way mobile and desktop apps currently work by bundling up all of the app's resource in a "package" which is downloaded and installed locally. The whole package then needs to be updated every time any of the resources change. This seems odd to me because this isn't the way the web usually works and it doesn't seem very web-like at all.

The fact that an individual resource can be identified by a URI is what makes it a part of the web, so to package resources up in one big bundle to be downloaded and used locally seems to break the web paradigm and therefore these apps are not "web apps" in my view, just apps downloaded over the web. This is how W3C widgets work and it's also how Chrome "packaged" apps work and seems to be the direction of the Wholesale Apps Community, the EU funded Webinos project and the Native Web Apps community on the W3C web site.

For an app to be part of the web, I think all of its resources (HTML, CSS, JavaScript, images etc.) must be identifiable by a URI. Resources which are needed when operating offline can be marked as such in an HTML5 cache manifest, which then also provides an automatic update mechanism when these resources are changed. This maintains one of the great characteristics of web apps which is their ability to be updated seamlessly with new features and bugfixes without the user having to manually upgrade to a new version. Mozilla Open Web Apps seem to work in this way, and so do Chrome's "hosted" apps.

Conclusions

It seems that web apps will be the preferred category of apps for a whole new generation of operating systems, but in order for these web apps to remain cross-platform new open standards must be agreed upon for APIs which give web apps all the power of native apps.

A mechanism for the discovery, installation and updating of hosted installable web apps and a trust framework which allows for secure open distribution is also something which I think desperately needs standardisation if the vision of a universal open web app platform is to be realised.

OStatus: Real-time Distributed Social Networking

tola — Wed, 02 Jun 2010 09:59:15 +0100

The current popular breed of social networking services are closed networks which don't connect with each other. If a user from one network wants to connect with a user on another network, they generally have to sign up for an account with the second network. This inconvenience ultimately results in a few very large networks with an inordinate amount of control over peoples' most personal data and a lack of choice and privacy for users.

Current Social Networking Services

In 2007 I wrote about an idea for building a distributed social network using a collection of existing open standards. The idea was to allow for social networking functionality equivalent to services like Facebook, but in a more open way where users can choose their provider or host their own data, but still connect with each other. The result would be a "network of networks" connecting to each other with open standards and ultimately much more control and choice for the end user.

Distributed Social Networking

Things have moved on a little since 2007 and a new collection of protocols has now emerged to allow near real time publishing of "activity streams" which can be discovered and commented upon within a social graph in an open, distributed way. You can think of this as a Facebook news feed, but without Facebook. Users will be able to choose from a whole range of different social networking services (or even run their own), and connect with their friends on different networks. Your news feed can then aggregate information from all of the people you're following across a range of different networks, update you about what's going on in near real time and allow you to send a response from your network to theirs.

OStatus is a collective name given to a suite of existing protocols which make this possible. They include:

PubSubHubbub - Real-time publishing ("PuSH")
ActivityStreams - Represent social actions in XML with Atom
Salmon - "Upstream" comments and replies
Portable Contacts - Social graph and contact data sharing
WebFinger - XML representation of a user's identity in terms of the services they use

The OStatus standardisation process is just getting started to define how these existing protocols can work together, but sites like Google Buzz, StatusNet, WordPress.com, and Tumblr are already implementing some or all of the protocols.

There are lots of projects which are working on the idea of distributed social networking. One which has attracted a lot of attention in the press recently is Diaspora which was recently started by a group of four students from New York University thanks to funds raised with an online campaign. The Diaspora team hasn't released any code yet, but they have committed to supporting OStatus. There are many other similar projects, including but not limited to:

Hopefully OStatus and some or all of these projects can do for social networking what SMTP & Sendmail did for email, what HTTP/HTML and Apache did for document sharing and what RSS/Atom and Wordpress did for blogging. If just some of these projects choose to support the OStatus group of protocols (some of them already have), then the social web will be a much more open place!

See OStatus.org and a presentation by Even Prodromou for more information.

Vivaty defects to Flash for Vivaty Scenes Lite

tola — Tue, 22 Sep 2009 09:25:00 +0100

This is a very sad day for open standards on the 3D web.

I'm devastated to hear that the X3D poster child that is Vivaty has stooped to shoe-horning a feature-limited version of its service into a proprietary 2D graphics plugin as a misguided attempt at achieving cross-platform support.

Yes, I'm a Mac (and Linux) user who would like to be able to use Vivaty, no I don't want to use a stripped down version hacked into Flash.

I wonder what great things could have been achieved if the engineering effort put into hacking together a 3D application in a 2D graphics engine had instead been ploughed into supporting and improving Unix/Linux-based implementations of X3D, the ISO standard for 3D graphics on the web. The Web3D community would benefit considerably from Vivaty's contribution to standardising and promoting the innovations they have made with the Vivaty Player, AJAX3D being one example.

I'm not angry at Vivaty's misguided efforts which were no doubt driven by business decisions, I am instead disappointed that they felt that the open standards route was not a viable cross-platform option for a company which has previously championed the standards movement.

O3D - Google's 3D JavaScript API

tola — Wed, 22 Apr 2009 08:58:00 +0100

I've been dying to talk about this since last summer when I joined the trusted testers programme, but the public release has finally arrived. Google has released an Open Source JavaScript API for creating interactive 3D graphics in the browser called O3D. It is currently a browser plugin for Internet Explorer, Firefox, Safari, and Chrome that works on Windows, Mac OS X, and Linux - but Google would ultimately like to see native support in browsers.

Although Google have been working on this project for two years, they're billing this as an early release as "part of a conversation with the broader developer community about establishing an open web standard for 3D graphics". With reference to Khronos' Initiative to Create Open Royalty Free Standard for Accelerated 3D on the Web, Matt Papakipos (Engineering Director at Google) has previously said "with more and more content moving to the web and JavaScript getting faster every day, the time is right to create an open, general purpose API for accelerated 3D graphics on the web. Google looks forward to offering its expertise in graphics and web development to this discussion".

A CNET article on O3D also quotes Papakipos. 'Google believes that it's possible that multiple 3D interfaces will be supported in browsers of the future. "Ultimately, there's going to be at least two," Papakipos said, pointing out that 2D graphics in the browser has two technologies at present, SVG and Canvas'. Having personally discussed X3D with Matt Papakipos, I have high hopes that he may be referring to X3D here, or perhaps a derivative of X3D. When I discussed X3D with members of the O3D team (known internally by a different name) last summer, they said they didn't know a great deal about X3D at the time, but they seemed to have some reservations about parts of the standard - apparently enough to warrant taking their own approach to the problem.

I am encouraging Web3D Consortium members to engage in this discussion. As Google has recently become a browser vendor and a member of the Khronos group, I would also be interested to hear the consortium's views on Google's recent release. Their new API is yet another example of an imperative approach in contrast with X3D's declarative approach.

Please note that I am not currently an employee of Google, I was only an intern there last summer, any opinions expressed are my own.