Mark Finkle wrote:
I like the level of detail in the doc. You didn't include Tabs as a
data type, but I think it's pretty easy to infer a structure based on
the definition of the other types. I have a few questions / comments:
The MVP product specs didn't talk about other data types. But yes, tabs
and form data should be easy to add.
"We assume that all changes to the local database occur in a
mostly-connected state. In other words, people don't change passwords
or bookmarks without network connectivity."
Given that mobile devices can be without mobile data service for
non-trivial amounts of time, do we need to add code that stops a user
from editing passwords or bookmarks? What about closing or opening
offline webapps in tabs?
What I was trying to say is that today most of our users are very
unlikely to be without data connection whenever they interact with a
browser. Its not impossible and its something we have to tolerate, but
its simply very rare and not something that we optimize for.
"We use push notifications to shorten the collision window"
This could be possible on Android, but the system already has a Sync
system built in. We should take a look to see if push could be used
within that system. I'm just trying to go with the grain of the OS
instead of fighting it.
dougt's push stuff should work everywhere. I am not sure exactly how he
does it on Android (using the platform push or his own long poll). dougt?
"Replicate from (overwrite local passwords with server values)."
This sounds like it could cause too much data loss. We'd need to think
about this a bit more. If the user has a set of passwords on a mobile
device, for pages that might have a mobile-specific domain or for
webapps they only frequent on mobile devices, it could wipe away a
large chunk of data that is not on the server.
We only overwrite what you already have on the server (collisions).
Additional passwords you just merge (its one doc per password, so those
don't collide).
"We expect dozens of bookmarks, and many hundreds worst-case"
Do we truncate or ignore trees that go over some predefined size
limit? Or do we continue to try to sync even large bookmark trees?
Good question. I think for desktop it doesn't matter. I was estimating
that 10000 bookmarks (pretty degenerate case) is around 1MB as JS object
graph. Compressed thats not too much data to shuttle around, and also
not too much data to have in memory in the desktop (or to jsondiff, as
needed). Even for mobile 10000 should work, though, nobody is going to
have that many in one folder. In other words I don't think we have to
limit. People will self-limit.
"Clients keep the current revision of a doc in shadow couchdb."
Does this imply that a copy of the full bookmark tree would be kept on
the device? What is the shadow for history or passwords since each
"record" is a doc?
Yes. We need to know the state of the server to be able to use diffs.
Its basically a text string for each doc (2 bookmark trees and each
password and history entry).
"Clients that have sync enabled should use our push notifications
protocol to listen to server changes."
You might be making too much of an assumption about FxAndroid using
Gecko to do the syncing. That likely won't be the case. It is an
Android service using Java.
Its a pretty simple Web protocol on a standards track. If we want to
stick with Java (I don't see why not), we should add it there as well.
dougt is the expert here.
Andreas
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
