Architecture in a nutshell

The locker is a bunch of web services that all natively speak REST and JSON to each other, all independent but connect to each other via one core web service, lockerd.js.

The core service:

• Installs services
• Starts/stops any service
• Manages how to access any service
• Passes events (push) between services
• Schedules upcoming task/job callbacks

Individual services themselves are designed to be very isolated and loosely coupled:

• They are started in their source code directory
• They are provided a single persistent working directory and localhost port to listen on
• Their working directory is for any stored state and data files
• Any "session" information is passed via STDIN on startup from core
• They should be be able to be turned off/on safely as needed
• Any interface and controls for the locker owner are via html5 served on /
• They always live behind a reverse proxy (core) that manages access
• All access is via straight HTTP, as services within a locker may be spread out across devices, computers, and cloud instances

Now, in order to know what services are providing what functionality and data formats, there is a concept called "service types" which provides a definition of:

• One or more REST calls
• The structure of the JSON data returned (attributes, values, etc)
• Other data types returned (thumbnails, files)
• What events are generated and their structure

Examples of service types are like contact/twitter, contact/gmail, photo/flickr, status/facebook, etc. Any service within the locker needs to define what types it provides, and can ask core how to reach or listen to other services based on their types.

That's pretty much it for the fundamental architecture in a nutshell! That's only part of the story though, very important is the common patterns that have been evolving around this architecture that most of the services are using in some form:

• Most of the services are very event driven and written in node.js, and others in python (but as above, the arch is ultimately language independent)
• The three general role patterns are services being either a:
• Connector - to external data source
• Collection - aggregation of common data types like photos, contacts, etc
• App - functionality built to experience/manage data from Connectors/Collections
• Some of the services with larger datasets are using Mongodb for lightweight indexing
• Any service syncing/archiving data should store it as simple JSON on disk for future accessibility

Coming soon: TeleHash and interconnecting lockers :)