There has been a lot of discussion and progress in the month since we announced our proposal for an “Open Web App Ecosystem”, and we wanted to provide a snapshot of our progress and current thinking. This post outlines a new feature, “Application Sync”, as well as several proposed technical changes to Open Web Apps.
The way the Web works today, changes made on a site are often transparently visible across all of a user’s devices, changes such as photos posted to Flickr or updates sent to Twitter. Given that many popular sites use server based storage behind an authenticated user account, this “feature” is quite natural for the Web.
Open Web Apps, on the other hand, are more similar to browser bookmarks than they are to photos on Flickr. The set of applications that a user has installed is persistent in a browser’s storage on the client, and is not stored on any central server by default.
A problem in user’s expectations arises here: the more and more the dashboard ends up feeling like a hosted Web application, the more a user will expect to see her stuff wherever she is.
To address this problem, we have included “application synchronization” as a first class feature. The goal of this feature is to allow a user to synchronize their applications between devices and browsers if they choose. We’ve begun prototyping synchronization, and you’re welcome to follow our progress on github.
Refining the Manifest
The application manifest format for Open Web Apps is a specification of JSON encoded meta-data that describes the presentation, launch, and capabilities of an Open Web App. This specification is central to the system we propose, as it will be an important integration point for application developers, browser vendors, and application stores.
Given the central role of the manifest, it has been the focus of a commensurate amount of attention. We have received feedback from standards groups, engineers working on “Installable Web Apps” at other browser vendors, companies and individuals interested in running application stores, application developers, and our own security experts here at Mozilla.
All of this discussion has culminated in a handful of concrete proposed revisions to the manifest format which attempt to build a more secure platform for Web apps that serve all parties involved in the ecosystem. You can learn more about the current proposed changes, and join the discussion, in a separate blog entry dedicated to refining the manifest.
Defining the Application Repository
One key component of Open Web Apps is what we’re calling the Application Repository. This is a client side entity that exposes an API to Web content: applications, stores, and dashboards. Its primary responsibilities are to manage the collection of installed applications and ensure that the user remains in control of them.
You can view the latest version of this API specification on github, and we’re especially interested in feedback from browser developers on this API. Our hope is that it will be possible to implement this API on browsers across mobile and desktop environments alike.
In the upcoming weeks we hope to complete a first prototype of application sync, and we will have a complete revision of the application manifest ready for further community review. Finally, we should have prototype add-ons complete for multiple browsers available for people to try out.
Our longer term goal is to have an Integration Release of the Open Web Apps concept ready by early next year, which will serve as a blueprint from which we can work with members of the community to help spark a vibrant new ecosystem of rich applications for your browser.