зеркало из https://github.com/mozilla/pjs.git
ec3a569796
- Some code refactoring: Creating file filesList.js, which contains generic functions for using file lists (arrays whose entries keep file names and statistics) and corresponding listing files. They can be (and are) used in another application, and previously were in file conflictCheck.js. conflictCheck.js is now even more focussed on the 2-way-sync logic of roaming. - Added some safe-exception-catches, and showing the error in the UI. Currently, the code just malfunctions (broken dialog buttons?) in that case. This should help with bug 244589 and bug 244720, if the fix below fails, and other future unexpected problems. - Making the status message actually show something. - Renaming dumbObject() to ddumpObject() to match ddump() for easier replace - fixed bug 246201 - infinite conflicts - less conflicts, if files non-existant - potentially transfer less (if we know we have the file already) - code doc improved - pref API usage In filesList.js: - Changing listing file to actually use Unixtime as claimed (breaks existing files, but should only cause conflicts once) - Using indexed file lists, should be faster, probably not significant for roaming - Allow last modified time to differ 1 sec, because of FAT inaccuracy, not needed for roaming - Option to allow newer files, not needed for roaming - Fixing bug 244589 and probably bug 244720 by moving dom creation after the empty filename check. - minimal API change for extractFiles() |
||
|---|---|---|
| .. | ||
| resources | ||
| src | ||
| Makefile.in | ||
| README.txt | ||
| jar.mn | ||
| plan.txt | ||
README.txt
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.