Labs/Ubiquity/0.2 Design: UI and Security Extensibility: Difference between revisions

From MozillaWiki
< Labs‎ | Ubiquity
Jump to navigation Jump to search
(Changed to architecture proposal 2)
(Framed UI extensibility in terms of the architectural diagram)
Line 20: Line 20:
== UI Extensibility ==
== UI Extensibility ==


Given a selection, I should be able to:
All UI components will interact with the '''UI Manager''' depicted in the proposed architectural diagram, which essentially serves as a [http://en.wikipedia.org/wiki/Facade_pattern 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".
* 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".
Line 28: Line 30:
:::''Implementation note: Look at <tt>CommandSource</tt>'s method to get all commands.''
:::''Implementation note: Look at <tt>CommandSource</tt>'s method to get all commands.''


Given a command, I should be able to:
Given a command, clients of the UI Manager should be able to:


* Figure out what objects the command takes.
* Figure out what objects the command takes.

Revision as of 19:24, 16 December 2008

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.

Ubiquity 0.2 Architecture Proposal 2.png

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.