Labs/Sprints/People: Difference between revisions

From MozillaWiki
< Labs‎ | Sprints
Jump to navigation Jump to search
Line 30: Line 30:


== API ==
== API ==
The component will provide a service which can be instantiated like so:
First you'll need to import the module:


<pre class="brush:js;toolbar:false;">
<pre class="brush:js;toolbar:false;">
let people = Components.utils.import("resource://mozilla/labs/People.js");
Components.utils.import("resource://mozilla/labs/People.js");
</pre>
</pre>


This service will support these API calls:
Once imported you'll have access to these API calls:


<pre class="brush:js;toolbar:false;">
<pre class="brush:js;toolbar:false;">
guid = people.add(object)
guid = People.add(object)
bool = people.remove(guid)
bool = People.remove(guid)
bool = people.update(object)
bool = People.update(object)
</pre>
</pre>


Line 47: Line 47:


<pre class="brush:js;toolbar:false;">
<pre class="brush:js;toolbar:false;">
[guid, guid2] = people.add([object, object2])
[guid, guid2] = People.add([object, object2])
[bool, bool2] = people.remove([guid, guid2])
[bool, bool2] = People.remove([guid, guid2])
[bool, bool2] = people.update([object, object])
[bool, bool2] = People.update([object, object])
</pre>
</pre>


Line 55: Line 55:


<pre class="brush:js;toolbar:false;">
<pre class="brush:js;toolbar:false;">
[object, ...] =  people.find(object)
[object, ...] =  People.find(object)
</pre>
</pre>



Revision as of 20:35, 5 August 2009

Overview

Drivers: Dan Mills (thunder), Aza Razkin (aza)
Get involved: by hopping onto #labs on irc.mozilla.org or clicking on Discussion and leaving your comments

Description
Create a component that stores people (contacts) data in nearly schema-less form, and provides a simple API to add, remove, replace, and find people.


Goals / Use Cases

  • ability to store arbitrary contact data in a loose JSON format
  • ability to combine contact information from multiple sources while keeping it separate at the same time ("meta-contacts")
  • fast searching of specific well-known fields
  • easy-to-use API, fully scriptable
  • should be kept to as few files as possible, and be easy to embed in multiple extensions (e.g. Jetpack and Weave)
  • needs to deal gracefully with version changes and schema upgrades

Non Goals

  • this sprint will not implement any UI or visible interfaces for users

Download

not yet

History

Both Jetpack and Weave have discussed possible features around people, and require Firefox to keep an easy to use database. For example, see JEP 15 for a proposed Jetpack API. It makes sense for multiple projects to share a database, and keeping it separate will make it easier to potentially uplift it to Firefox as well.

Proposed Design

Structure

There will be a single XPCOM component implemented in JavaScript, and an IDL file to go along with it. The component can then be dropped into any extensions that need to use the interface, and eventually uplifted into Firefox.

API

First you'll need to import the module:

Components.utils.import("resource://mozilla/labs/People.js");

Once imported you'll have access to these API calls:

guid = People.add(object)
bool = People.remove(guid)
bool = People.update(object)

The same calls also support multiple items passed in as arrays:

[guid, guid2] = People.add([object, object2])
[bool, bool2] = People.remove([guid, guid2])
[bool, bool2] = People.update([object, object])

And there is also a find method:

[object, ...] =  People.find(object)

In all cases the structure of the object will only be loosely defined, but could look something like this:

{"firstname": "John",
 "lastname": "Doe",
 "identities": [
   {"type": "gmail",
    "firstname": "Johnnie",
    "email": "jdoe@gmail.com", ...}
 ]
}

Performance

  • Certain well-known fields (e.g., "firstname") would be automatically indexed by the component, so that find() can do quick lookups for the common case.
  • Lookups including slow fields would have to be slower. We can selectively add more indexes later on if needed.
  • add/remove/replace would be as fast as sqlite can be
  • Should use asynchronous calls to improve user experience - this means callbacks though (or we need to process events in the meantime)

Security

  • this is an internal API only.

Testing

We should create unit tests, though those tests do not need to go into each extension.

References