mirror of
https://github.com/rn10950/RetroZilla.git
synced 2024-07-02 23:40:42 +02:00
44 lines
2.4 KiB
Plaintext
44 lines
2.4 KiB
Plaintext
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.
|