Closed Bug 18043 Opened 20 years ago Closed 16 years ago

Allow bookmarks to reside remotely on an arbitrary user-defined host

Categories

(SeaMonkey :: Bookmarks & History, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 124029
Future

People

(Reporter: ezh, Assigned: bugs)

References

(Depends on 1 open bug)

Details

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:/.../...
Assignee: leger → don
Component: Browser-General → XPApps
QA Contact: leger → claudius
Target Milestone: M20
putting on correct component radar to get considered.
Component: XPApps → Bookmarks
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.
Target Milestone: M20 → Future
Could somebody fix the summary of this bug? The current one isn't particularly 
helpful, or descriptive.
Summary: Bookmarks on the net. Again bookmarks... :) → RFE: allow bookmarks to reside remotely on an arbitrary user-defined host
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
Netscape Nav triage team: this is not a Netscape beta stopper.
Keywords: nsbeta1-
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)?
Summary: RFE: allow bookmarks to reside remotely on an arbitrary user-defined host → [RFE] Allow bookmarks to reside remotely on an arbitrary user-defined host
*** 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.
Depends on: 83004
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...

No longer blocks: 17048
Blocks: 17048
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.

Depends on: 105178
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.
Assignee: vishy → ben
I did a proof of concept patch for this issue in bug 158964.
Summary: [RFE] Allow bookmarks to reside remotely on an arbitrary user-defined host → Allow bookmarks to reside remotely on an arbitrary user-defined host
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. ***
No longer blocks: 17048
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 ***
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.