gecko-dev/extensions/sroaming
timeless%mozdev.org db820cf720 Bug 106386 Correct misspellings in source code
patch by unknown@simplemachines.org r=timeless rs=brendan
2005-11-25 08:16:51 +00:00
..
resources Bug 106386 Correct misspellings in source code 2005-11-25 08:16:51 +00:00
src Adding MOZILLA_INTERNAL_API to internal makefiles, bug 288626, rs=darin 2005-04-04 18:38:19 +00:00
jar.mn bug 278301 - sroaming should use localeVersion from chrome-versions.sh, r=ben.bucksch, sr=neil 2005-01-15 15:18:10 +00:00
Makefile.in Bug 124029 - Roaming 2004-05-24 16:55:07 +00:00
plan.txt 246710, should also fix 244589, 244720, 246201 2004-06-17 16:21:18 +00:00
README.txt Bug 124029 - Roaming 2004-05-24 16:55:07 +00:00

This implements 4.x-like roaming.

To make the implementation vastly more simple, it has been decided that no 
syncing during the session happens. The design will not allow that either 
(at most sync in certain intervalls). A full-blown dynamic implementation 
that immediately update the server when a data change occured requires the 
cooperation of the data providers (bookmarks, prefs etc.) and is thus a huge 
change that I will leave to somebody else to implement independant of this 
roaming support here. alecf made such proposals a longer time ago on 
n.p.m.prefs, they sounded very interesting, but unfortunately, nobody 
implemented them so far.

When the users selected a profile, we will check, if it's a roaming profile 
and where the data lies. If necessary, we will contact the server and 
download the data as files. We will overwrite local profile files with 
the downloaded ones. Then, the profile works as if it were fully local. 
When the user then logs out (shuts down Mozilla or switches to another 
profile), we upload the local files, overwriting those on the server.

Following Conrad Carlen's advise, I do not hook up using nsIProfileChangeStatus, 
but in nsProfile directly. That just calls |nsISessionRoaming|. 
Its implementation uses various protocol handlers like |mozSRoamingCopy| to 
do the upload/download. These in turn may use generic protocol handlers like 
the netwerk HTTP protocol to do that.

Also following Conrad's advise, I do not store the roaming prefs in the prefs 
system (prefs.js etc.), because that it not yet initialized when I need the 
data (of course - prefs.js, user.js etc. might get changed by us), but in 
the Mozilla application registry. For the structure, see the comment at 
the top of prefs/top.js.


Overview of implementation:
- transfer.js (the Transfer class and support classes) contains the
  non-GUI logic to transfer files and track the progress and success.
- progressDialog.* shows the progress to the user (and also works as interface
  to the C++ code)
- conflictCheck.js is the "controller", controls the overall execution flow.
  It determines what has to be done (which files to transfer when etc.),
  including the conflict resolution logic, and kicks off the transfers.
  There is a long comment at the top describing the implementation.
- conflictResolution.* is a dialog to ask the user when we don't know which
  version of a file to use.