CloudServices/Roadmaps/Sync/Client: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 52: Line 52:
|projName=Improve discoverability}}
|projName=Improve discoverability}}
{{ServicesSeqItem
{{ServicesSeqItem
|anchorName=.5BP2.5D_Remove_backwards-compat_code_.283.5.2F3.6.29
|anchorName=.5BP2.5D_Remove_compat_code
|projName=Remove compat code}}
|projName=Remove compat code}}
{{ServicesSeqItem
{{ServicesSeqItem
|anchorName=.5BP2.5D_Remove_backwards-compat_code_.283.5.2F3.6.29
|anchorName=.5BP2.5D_Remove_compat_code
|projName=War on Sync}}
|projName=War on Sync}}
# War on Sync
# War on Sync

Revision as of 22:37, 31 March 2011

Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
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

[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] Push 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.

Stability and Performance

[P1] War on Sync

[P2] Crossweave 2.0

[P2] Remove compat code

[P3] Automatic profiling

Sequence

  1. Improve discoverability
  2. Remove compat code
  3. War on Sync
  4. War on Sync
  5. Instant Sync
  6. Improve setup
  7. CrossWeave 2.0
  8. Send to mobile
  9. Sync add-ons
  10. Sync favicons
  11. Sync web apps
  12. Sync localStorage
  13. Automatic profiling