Let's make Mozilla's bookmarks the best bookmarks it ever gave! :) I use 2 computers. At office and at home. I wish to store my bookmarks on a Internet server and automatically DL it every time I start Mozilla. So when I change bookmarks at work I don't need to send to home which URL I added, deleted or moved. So bookmark file should be allowed to be on www.xxx.xx/.../..., not only on local drive X:/.../...

putting on correct component radar to get considered.

Couldn't this be done with roaming profiles?

Is this the same as bug 17917 - [RFE] Add "smart" roaming bookmarks (etc.) with sync capabilities?

Tep, sounds like a dup. But the difference: I want to place the bookmark file where I want, on a freeserver, ftp, etc.

Move to "Future" milestone.

Could somebody fix the summary of this bug? The current one isn't particularly helpful, or descriptive.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

Netscape Nav triage team: this is not a Netscape beta stopper.

This needs to be specified more closely! This looks like a simpler version of bug 17048 (supposed to provide more general synchronizing of bookmarks, preferences etc but requires ACAP/LDAP or something alike). Is there a need for this simpler variant (just uploading and downloading the plain bookmarks.html file to some URL)?

*** Bug 72413 has been marked as a duplicate of this bug. ***

I think a good extention to this would be to allow a user to add subsections to their bookmarks which are actualy sepparate bookmark repositories on a server or something so that sharing bookmarks with others is made simple.

Chris: That's what 72413 is about (which is not, as it turns out, a duplicate of this one, though it might be a superset).

ACAP is one suggested technology for 17048, which would also allow this. It supports inheritance (allowing inheritance from a base with local customizations) and, I believe, references to remote datasets.

I'd like to consult my design of "bookmarks" storable in LDAP server. Anybody interested in look at http://runner.ascs.muni.cz/LDAP/index.php?file=LDAP_projects.html. it would be nice to get consensus on some design good enough to promote later to mozilla. Thanks.

binary_runner: runner.schema appears to be unreadable on your server; can you fix that? Generally it seems like a reasonable architecture, but since I've never touched the bookmarks code, I don't feel qualified to really endorse it or not. I've added Ben Goodger to the CC list of this code; perhaps he has some thoughts...

fixed, I'm sorry for that; tomorrow my computer will be disconnected from network but I'm making steps so the docs will be still available under the same URL, it can lead to short period of short behaviour

add to cc list

To provide some persistent site for LDAP bookmarks project I've created project at mozdev (http://wwwampire.mozdev.org/), when I will found how to access parts of object class hierarchy and/or its depth from XUL template I hope there will be also first primitive but functional example (read-only, of course). It uses Dublin Core attributes stored in custom LDAP object classes. Any sugggestions are welcome.

This simple implementation is of course very useful! It may be hard to convince other browsers' (Opera, IE, Lynx, Konqueror, ...) developers to implement a too complicated feature that is not really needed at that scale of complexity. But maybe we should just write a little _external_ tool that does all that. One could put it into the crontab files on UNIX/Linux systems and run it manually on other systems... a double-click should not be too much work for the user. Anyone knows any GNU licensed bookmarks conversions utilities/sources?

Reassigning to a real person.

I did a proof of concept patch for this issue in bug 158964.

Could this not be done using an extention of the idea behind bug 72413; If a bookmark file is made up to include references (eg iframes) to other bookmark files, the local bookmark.html file can have only one entry, the reference for the remote store. Thus all bookmarks located in the remote store folder are accessible by any machine with access to the remote file.

It will do bookmarks sharing difficult. The solution using LDAP as store of bookmarks seems better for me as you have fine-grained access rights and the bookmarks data are accessible to other applications too (important for automatic processing of bookmarked resources). Your solutions looks to fragile to me.

dup of bug 158964? (because that one has a patch)

*** Bug 201736 has been marked as a duplicate of this bug. ***

maybe someone interested in this bug is also interested in this script http://booksync.mozdev.org/index.html while the bug gets fixed.

*** Bug 236738 has been marked as a duplicate of this bug. ***

Many currently existing implementations of this idea have a large bug, IMO, in that they just download the bookmark file at the beginning of the session and upload it at the end. This causes problems when the browser crashes, as the updated bookmarks are not uploaded. More problems happen when two browser sessions are open at once, creating the problem that the last one to close overwrites the updates of the earlier one. I'd like to try to make sure that when this gets implemented that this doesn't occur. I don't think it needs to go so far as to be truly random access (so that bookmarks added in one of multiple concurrent sessions show up in the others), though it would be very nice, but it definitely needs to update the remote database dynamically and be able to resolve update conflicts.

Session roaming (recently checked in in bug 124029) can up/download selected profile files (incl. bookmarks) to/from a server. > Many currently existing implementations of this idea have a large bug, IMO, in > that they just download the bookmark file at the beginning of the session This is not a bug, but a design decision, thus the term "session". > This causes problems when the browser crashes, as the > updated bookmarks are not uploaded. No problem, it will be uploaded the next time the browser closes normally. > More problems happen when two browser sessions are open at once True, that's not allowed with session roaming. Session roaming at least tries hard to detect such conflicts and give you the choice which version to use.

From a design perspective, perhaps it would make the most sense to store changes on the workstation for periodic (say every 2 minutes) background updates. This will allow changes to be committed before the end of the session avoiding the problem of the browser crashing but at the same time avoid the problem that each bookmark implies a network transaction and also allow for receiving new bookmarks remotely added. On conflict resolution, it seems to me that not much needs to be done. Each bookmark could be a separate record (where the database could be an actual RDBMS, an LDAP tree, or some other data/directory server that allows record-level updates). Deletion isn't something that has conflicts. Deleting something twice means nothing more than deleting it once. Likewise, addition could be idempotent, perhaps taking into account the particularly bookmark folder into which it's placed, allowing multiple bookmarks for the same thing as long as they're in separate folders. Or maybe it just allows multiple additions of the same bookmark. This should be a relatively rare occurrence. Likewise, editing conflicts should be fairly rare. Typically users of a profile will not be using two different browsers at once. If they are, they'll still probably not be updating the same bookmark simultaneously. In the rare event that they are, why not just allow the most recent change to be the persistent one. It should be rare enough that some sort of manual resolution is unnecessary.

Trevor -- see bug #17917: "Add "smart" roaming bookmarks (etc.) with sync capabilities". *This* bug I think can be considered fixed as part of bug #124029.

Yes, dup of either roaming (bug 124029) or bookmark sharing (bug 17917, probably more dups). Picking the former, because it satisfies the summary. *** This bug has been marked as a duplicate of 124029 ***