Introduction
As per the first Ubiquity planning meeting, our goals for 0.2 are to:
- make Ubiquity easier for experimental new UIs to leverage, and
- make Ubiquity more secure.
The implementation of (1) will involve providing a well-documented API for external UIs to plug into. The implementation of (2) will involve providing a "feed plugin" mechanism through which new types of Ubiquity feeds can be created that use entirely different security models than Ubiquity's default.
Both of these solutions invite community members to create and implement new ideas to further the conversation about using the browser to connect web services together in a safe, humane way.
Before reading the rest of this document, it may be helpful for readers to understand the Ubiquity 0.1.3 Architecture.
Proposed Architecture
Below is the proposed architectural diagram for 0.2. Its individual parts are explained in the following sections of this document.
UI Extensibility
All UI components will interact with the UI Manager depicted in the proposed architectural diagram, which essentially serves as a facade to Ubiquity's functionality.
Given a selection, clients of the UI Manager should be able to:
- Determine what commands are apropos to operate on it. For instance, if I select a street address, one of the first commands that it matches should be "map".
- Implementation note: Look at the CommandManager's noun-first-suggestions code.
- Get a list of all commands that can apply to the selection.
- Implementation note: Look at CommandSource's method to get all commands.
Given a command, clients of the UI Manager should be able to:
- Figure out what objects the command takes.
- Implementation note: Once we unify Verbs and Commands, this will be trivial.
- Call the command.
- Implementation note: see above.
Security Extensibility
The main idea here is to decouple Ubiquity's user interface from its implementation so that it's easier to experiment with more secure implementations. Another benefit of this is that it'll be easier to unify Ubiquity's UI with other pre-existing forms of web extensibility, like Bookmarklets and Greasemonkey scripts.
In Ubiquity 0.1, command authors create a command feed by inserting an tag of the following form in the <HEAD> element of an HTML document:
<LINK REL="commands" HREF="my_commands.js" TYPE="application/x-javascript" />
In Ubiquity 0.2, the values of the REL and TYPE attributes will be used to locate an appropriate Feed Plugin for the feed. Much of what happens next is delegated to that plugin.
Creating a new Feed Plugin has the following requirements:
- The Feed Plugin will be responsible for actually loading the feed and providing its functionality—generally in the form of commands and pageload functions—to Ubiquity using well-defined interfaces.
- The Feed Plugin will control the user experience from the moment they click the subscribe button in the notification box to subscribe to the feed, presenting any necessary information the user may need to know before subscribing (e.g., security warnings). It will also be responsible for communicating with the Feed Manager to actually subscribe to the feed, since it's possible that the user may ultimately choose not to subscribe.
- The Feed Plugin will have optional interface elements and information it can display on Ubiquity's feed management page (currently located on about:ubiquity).
Requirement (1) will provide Feed Plugins with the freedom to implement whatever security model they need, while requirements (2) and (3) will give them the ability to present that model to the end-user in an understandable way.
It should also be possible for one Feed Plugin to wrap another, creating possibilities for middleware. For instance, a social web-of-trust style model could be layered on top of an object capabilities model, thus providing multiple layers of protection for end-users.