Closed Bug 374518 Opened 14 years ago Closed 14 years ago
Provide platform support to enable syncing of Places datamodel objects to a remote server
108.32 KB, patch
|Details | Diff | Splinter Review|
113.74 KB, patch
|Details | Diff | Splinter Review|
88.57 KB, application/x-xpinstall
113.02 KB, application/x-xpinstall
This is a tracking bug for item PLCS-001a in the Firefox 3 PRD.
Target Milestone: --- → Firefox 3 alpha5
Flags: blocking-firefox3? → blocking-firefox3+
retargeting bugs that don't meet the alpha release-blocker criteria at http://wiki.mozilla.org/Firefox3/Schedule.
Target Milestone: Firefox 3 alpha6 → Firefox 3 beta1
A rough sketch of what a sync service might look like to sync the places bookmarks to a remote server. Includes some unnecessary UI I added to test the service. A sample server is available here (too large to attach to the bug): http://sandmill.org/~thunder/sync/
This implementation requires no special server-side code. It uses HTTP 1.1 GET/PUT (and will use WebDAV locks when available, that just needs a little work). It also supports uploading/downloading deltas (instead of a complete snapshot). The only thing missing is code to upload a new snapshot when the deltas file grows too big. Note, this patch includes no UI (it's only the sync service), but I'll upload a simple xpi that adds a toolbar button for testing.
Thunder, is there anything left to do here for platform support? The sync client implementation work should be moved to bug 374519.
Right, the attachments are here as proofs of concept to prove sync can be implemented with the current API. I'd like to get some feedback from Foxmarks and/or del.icio.us before closing off this bug, though. Do you agree? Both sync implementations here ultimately rely on sync.js, so it would be good to get a second opinion from someone with a different sync approach.
Hello, I have been playing around with the code in these attachments but files seem to be missing from the latest Minefield trunk build (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007-07-31-05-trunk/, using Windows). We have gotten Helma and Dan Mills' stuff up an running but when clicking the sync test button the following is shown in the Error console: Error: Cc['@mozilla.org/places/sync-service;1'] has no properties Source File: chrome://ttb/content/ttb.js Line: 5 Line 5 contains: syncsvc = Cc["@mozilla.org/places/sync-service;1"].getService(Ci.nsIBookmarksSyncService); Is there anything special that must be configured to enable places/sync-service? Or is it just nsIBookmarksSyncService.js that is missing from the distribution?
(In reply to comment #7) > Error: Cc['@mozilla.org/places/sync-service;1'] has no properties > Source File: chrome://ttb/content/ttb.js Line: 5 The patches on this bug are proofs of concept only, and haven't been committed to the tree. So you'd need to apply the patches and make your own builds to try them.
(In reply to comment #8) > (In reply to comment #7) > > > Error: Cc['@mozilla.org/places/sync-service;1'] has no properties > > Source File: chrome://ttb/content/ttb.js Line: 5 > > The patches on this bug are proofs of concept only, and haven't been committed > to the tree. So you'd need to apply the patches and make your own builds to > try them. > It'd be cool if these were converted to an extension, so that it could be used as a starting point for extension developers. Dan, what would it take to be able to do this?
I think it would be pretty easy, specially for the 2nd patch. I'll add that to my todo list.
(In reply to comment #6) > Right, the attachments are here as proofs of concept to prove sync can be > implemented with the current API. > > I'd like to get some feedback from Foxmarks and/or del.icio.us before closing > off this bug, though. Do you agree? Both sync implementations here ultimately > rely on sync.js, so it would be good to get a second opinion from someone with > a different sync approach. > pushing to M9 (or later) given that this will be ongoing.
Target Milestone: Firefox 3 M8 → Firefox 3 M9
Set the 'browser.places.sync.serverUrl' to your own server's URL to try it. It only requires HTTP GET/PUT as it is (the WebDAV LOCK support is commented out atm).
Given the prototypes here, and recent conversations with Foxmarks where they said that they can work with the current API, I'm closing this bug as fixed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
verified through bake time
Status: RESOLVED → VERIFIED
Dan, when I try to install your XPI, I get an error message: ----- Firefox could not install the file at https://bugzilla.mozilla.org/attachment.cgi?id=275738 because: Install script not found -204 ----- Is that expected?
Hey Mikel, The extension here is not packaged correctly, you're right, but it eventually became Weave, which you can get at https://services.mozilla.com/
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.