CloudServices/Roadmaps/Sync/Client: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(No difference)

Latest revision as of 19:54, 19 November 2013

Syncicon.png Sync 2011 Roadmap
Owner: Jennifer Arguello Updated: 2013-11-19
As an organization, we have three main areas of focus: Desktop, Mobile and Apps. Sync and other Services (such as Identity, Social) form a critical foundational piece for each of these areas. Not surprisingly, the priorities for Sync are driven a lot by what we are hoping to achieve on each of these major focus areas. Additionally, there are various areas of user pain that we should address.

Introduction

Themes for 2011

What we a looking to tackle in 2011.

  • Improve Sync Discoverability
  • Improve Usability
  • Improve Performance
  • Sync More

Desktop

This is where most of our users are. This is where they do the most of their browsing and generate most of the data that they want to take everywhere. We should sync more of this data transparently. Here's a prioritized list of data types to sync:

  • Add-ons & jetpacks
  • Search engines
  • Favicons
  • Site specific prefs
  • Client certs

We should tune our Syncing behavior to be more specific to the data being synced. There are a couple of options we should pursue:

  • Move to an instant Sync model for bookmarks and stored passwords - no user action needed.
  • Move to a user triggered Sync model for get up and go (send tabs to phone). This would also be instantaneous.

Additionally, we should implement notification based Syncing to explore efficiencies it might bring to the system (experimental).

Finally, as we encourage users to organize their tabs into groups (via Panorama, for example) that make sense to them, we should Sync those tab groupings to the cloud. Applications (such as Firefox, Fennec etc) may then use that meta data to display tabs in views that make the most sense on the form factor they're being viewed in. In 2011, we should move to a model where the cloud becomes the authoritative source of your tabs (and groupings) that are then streamed to your devices/applications.

Mobile

This is where we want to increase our value for users the most. The current use cases of get up and go and never start from scratch are both pretty well catered to by Sync. However, there's definite room for improvement.

  • We should provide enough meta data to enable snippet view (ala SpeedDial) for the redesigned Fennec Start Page.
  • Favicons sync mentioned above also helps with instant identification.
  • Implementing a Send to Phone feature would also make the get and up go experience better and more reliable.

In 2011, Firefox Home is becoming a web app. This means we will need to provide web access to your Sync data. The core set of data that would be immediately useful is:

  • Your most frequently accessed sites/web apps.
  • Your bookmarks.
  • Your remote tabs.

But more importantly, we will need to implement mechanisms for web content to get access to your Sync data. One approach we should experiment with is giving users the ability to opt-in to getting web access to their Sync data by opting out of having that data encrypted client side. We should still continue to Sync over SSL.

Apps

Our apps strategy is still in the works, but there are definite requirements on Sync. In particular, we should:

  • Sync your list of installed web apps.
  • Provide a mechanism for web apps to selectively Sync contents of localStorage.

Note that there is no requirement to have this information be encrypted. There is already some prototype work done by Ian from the Apps team that is documented here: https://github.com/mozilla/openwebapps/blob/master/docs/SYNC.md

A few other areas that we will need to work out:

  • Performance benchmarks
  • Support data format changes without requiring coordinated releases
  • Offer more storage
  • Evangelism to get add-on developers and app developers to store data on the Sync servers
  • Engineering changes required to make Sync work with/under e10s

Additionally, we should add better device management controls through our web based accounts portal. In particular, users should be able to:

  • (NEED TO MOVE THIS OUT OF SYNC ROADMAP) Deauthorize devices. Users should be able to able to stop stolen or lost devices from syncing and getting access to their precious data.

What are we not doing in 2011

  • Monetization based on selling more space. Note that we should be open to other BD opportunities (such as partnering with Dropbox, for example) that could open up revenue streams to sustain Sync, but we won't be selling storage space in 2011.


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.

Measuring Success

TBD: Jennifer will fill this in.

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] Promote Sync in bookmark and password doorhangers

  • 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] Sync Setup Improvements

  • Improvements to the overall flow.

[P2] Push to device

  • 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.

[P2] Sync Migrate to Digest Auth

  • Hashing out ideas for migrating from BasicAuth - using DigestAuth for strawman

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 Spinning the Event Loop

[P1] War on Sync I/O

[P2] TPS, formerly known as 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.

Please go to the Sync Client Sequence page.

Retrieved from "https://wiki.allizom.org/index.php?title=CloudServices/Roadmaps/Sync/Client&oldid=765763"