CloudServices/Roadmaps/Sync/Client
|
THIS PAGE IS A WORKING DRAFT | 
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
Introduction
Context and goals
In Firefox 4 for desktop and mobile, we shipped Firefox Sync as a built-in component for the first time. The user and press feedback has been generally quite positive, and this document is our plan for improving and extending the client pieces over the rest of 2011. This is a document that may change over time to reflect evolving priorities.
Priority vs. sequence
In the new release process, where we branch every six weeks, attempting to align future work with specific releases is unlikely to be accurate, so this document does not attempt to specify this. This document is a statement of both direction and intent, laying out both the priority (how important we consider each piece of work) and sequence (the order in which we intend to attack these pieces). In a world without technical debt or design mistakes, these would be one and the same, but in reality there are often projects that need to happen sooner in order to make the cooler projects easier/faster/more stable. As with the paying down of any form of debt, strategy is key, and we are attempting to balance the two here.
Projects
Features and Enhancements
This set of projects is all about new features and other user-facing changes. From a product perspective, this is the real priority list, but various projects have dependencies that will alter the overall sequence.
[P1] Improve discoverability
- Project to increase exposure of Sync and drive increased adoption.
[P1] Instant Sync (engine specific sync heuristics)
- "Instant" may be misleading, but essentially this is much more aggressive syncing of certain data types (i.e. bookmarks, passwords) and smarter sync-on-return-from-idle behaviour.
[P1] Improve Sync setup process
- Waiting on user study, as yet unscoped
[P2] Send to mobile
- Feature enabling explicit "open this tab on device X"
- Implementation TBD, may use Notifications if ready, or may be an aggressively-synced engine using the pure Sync architecture.
[P2] Sync add-ons
- Add/update/remove automatically across computers
- Open question, to be decided at design/implementation time, as to whether this syncs across apps, or is per-app like prefs
[P2] Sync favicons
- This is less painful than we think, should be able to sync the moz_favicons table in some reasonable way.
[P2] Sync web apps
- Waiting on web app evolution
[P2] Sync localStorage
- Need to figure out space reqs, this will likely push us into "omg" levels of quota for some users
- Also highly non-trivial to do conflict resolution. localStorage is essentially a flat object, afaik no timestamps. Easy to get web app's data into inconsistent state --philikon
[P2] Snippet view in about:home
- This is pretty handwavy for now.
Stability and Performance
These projects are all tied to making existing code faster/more stable/easier to maintain and build upon. While in general they are not directly tied to any feature work, some are considered prerequisites or at least highly-desired precursors for some of the above features.
[P1] War on Sync
- Don't spin the event loop bug 600059
- Introduce async APIs across SyncEngine, Store, Tracker
- also see WEP 116
- Avoid synchronous I/O *everywhere*. Needs async bulk APIs in platform:
- forms
- passwords
- bookmarks
[P2] Crossweave 2.0
- lives in services/sync/tests/...
- maintained by us, run by tinderboxes
- mochitests? mozmill?
- JSON test file format (avoid custom format + parser), possibly even JS
- moar end-to-end tests
- tests the hell out of bookmark dupe detection
- test all obscure bookmark types (queries, etc.)
- need to test errors and edge cases as well
- run on fennec
[P2] Remove compat code
- use Services, XPCOMUtils where possible
- use NetUtil.BadCertHandler?
- implement + use toolkit generic async resource bug 581560
[P3] Automatic profiling
- are we JITing everywhere?
- main thread blocking (UI responsiveness)
- memory leaks
Sequence
In order to maximize developer effectiveness and product quality, we intend to follow the sequence below when tackling this set of projects. As the team grows, we'll pick up speed.