Labs/Ubiquity/0.2 Design: UI and Security Extensibility

Introduction

As per the first Ubiquity planning meeting, our goals for 0.2 are to:

1. make Ubiquity easier for experimental new UIs to leverage, and
2. 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

Given a selection, I 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, I 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.