Loop/Architecture: Difference between revisions
| Line 16: | Line 16: | ||
* Node.js for Loop server, at least through production | * Node.js for Loop server, at least through production | ||
* webl10n for Localization ({{bug|972884}}) | * webl10n for Localization ({{bug|972884}}) | ||
* Mocha and Chai for | * Mocha and Chai for client-side and standalone-page unit-testing framework ({{bug|976133}}) | ||
* Not using client CSS toolkit at the moment (this may be revisited) ({{bug|976854}}, {{bug|976857}}) | * Not using client CSS toolkit at the moment (this may be revisited) ({{bug|976854}}, {{bug|976857}}) | ||
Revision as of 18:04, 21 April 2014
Design Goals
Underlying Technologies
Mozilla Technologies
The Loop project relies on a number of other technologies under development within Mozilla. These include the following:
- WebRTC
- Firefox Accounts
- Simple Push (bug 976789)
- Social API (bug 971987)
- Marionette for client side unit-testing framework (bug 976127)
Third-Party Technologies
- Node.js for Loop server, at least through production
- webl10n for Localization (bug 972884)
- Mocha and Chai for client-side and standalone-page unit-testing framework (bug 976133)
- Not using client CSS toolkit at the moment (this may be revisited) (bug 976854, bug 976857)
Open Issues
These technology choices will be moved into one of the preceding sections as decisions are made:
- Client MVC Library + associated libs (bug 975548) -- Probably Backbone
- Client-driven end-to-end framework (bug 976114)
- Standalone-page end-to-end system testing framework (bug 976134)
Network Architecture
Data Flows
Note that these are currently described in terms of a REST (or, at least, REST-like) interface on the Loop server. There is a significant possibility that this interface will evolve to be JSON objects exchanged on a WebSockets connection, similar to the network API exposed by the Simple Push Server.
User Connects
User Generates "Call-Me" URL
Non-User Clicks "Call-Me" URL
User Rejects Call
Note that the exact means by which Bob receives pending call status is still an open issue -- periodic polling is easy, but might not scale as well as we'd like. Long polling is a potential improvement, but also has scaling implications. Ultimately, websockets may be the preferred approach here.







