285340 - web-based bookmark syncronization

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Bookmarks, enhancement)

Description

[Mike McGranahan]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

A web-based bookmarks synchronizer is one of two features that keep me from
switchin to Camino from Firefox.  The feature should be interoperable with any
feature pursued by Firefox (perhaps making this a feature request of Mozilla
overall).  Ideally it would support SFTP, FTP, HTTP, and HTTPS.  There is
discussion of a .Mac/iDisk implementation of this feature here
https://bugzilla.mozilla.org/show_bug.cgi?id=228123 but iDisk requires paid
subscription, which seems to oppose the Free Software spirit to me.

Reproducible: Always

Steps to Reproduce:

Comment 1

[L. H.]

So users would have to run their own FTP servers to do bookmark synchronization?

Comment 2

[Samuel Sidler (old account; do not CC)]

Confirming as new and targeting for Future.

Also, while this bug isn't truly dependent on 228123, it will probably come
after it and I imagine will use a similar method for publishing.

Can we have discussion on whether this should even be done? Seems like .Mac
support with Tiger would be enough.

Comment 3

[Mike McGranahan]

(In reply to comment #1)
> So users would have to run their own FTP servers to do bookmark synchronization?

The users to whom this feature would appeal would likely have the pre-requisites
to running their own server (FTP hardware and software, technical skill, and
motivation).  1)  They posess higher than average technical ability.  This is
true because installing Camino requires the ability to discern the advantages of
Camino over Safari.  2)  They possess drive/motivation.  This is true of
technical ability. This is true because to use Camino, the user must educate
themselves about Camino/seek it out, and install it. 2)  Access to FTP server
hardware and software.  People would most likely use perform bookmark syncing
between their personal Camino settings stored on two separate Mac OS X machines.
 Mac OS X has a built-in, easy-to-configure FTP server (as well as Apache though
I'm not sure if WebDAV is enabled by default).  For those that would want to
sync between the Camino settings of different user accounts on the same Mac OS X
machine, they could simply run the FTP server locally.  

(In reply to comment #2)
> Confirming as new and targeting for Future.
> 
> Also, while this bug isn't truly dependent on 228123, it will probably come
> after it and I imagine will use a similar method for publishing.
> 
> Can we have discussion on whether this should even be done? Seems like .Mac
> support with Tiger would be enough.

.Mac would be enough... for those willing to pay (currently US$99.95 per year)
for .Mac.  The fact that Free alternatives (Apache/mod_webdav) exist; that .Mac
is for-fee and making it a requirement to use a feature of Camino is effectively
endorsing a third-party, for-fee service; that .Mac administration, existence,
and reliability is entirely beyond the control of the user or the Camino
project, inidcate the need for implementing alternatives to, or at least in
addition to, .Mac support.

Implementation details also are important in determing the feasibility of
extending .Mac bookmark sync support to well-supported open protocols.  Since
the .Mac iDisk is mounted as a normal filesystem, bookmark sync /could/ be
implemented merely as permitting the user to determine a location to store their
bookmark data file (and the user would choose something like
/Volumes/iDisk/bookmarks.plist ).  In this case, the user could use Finder to
mount a WebDAV store and point Camino to it using the same facilities (in fact,
this type of implementation would permit use of any mountable storage, such as
USB flash drive, or LAN/VPN SMB share).  The remaining implementation issue
would be the recourse Camino would have in the event the user-specified bookmark
storage location was inaccessible (iDisk not mounted, no network connectivitiy,
flash drive not connected).

Alternatively, the implementation could specifically use iDisk to store a copy
of the bookmark data.  (Perhaps .Mac API [
http://devworld.apple.com/internet/dotmackit.html ] could be used as suggested
in the #228123 discussion, or filesystem access of iDisk, or integration into
iDisk). Extensibility to non-.Mac services in this case is obviously more
difficult.  One workaround might be for the user to setup a fake .Mac server and
direct DNS queries for www.mac.com or idisk.mac.com to one's own server (editing
/etc/hosts file or running a DNS server--bleah!) as described partially here
http://www.drijf.net/dototto/wwwmac.html .

I think the best compromise would be permitting the user to choose a
"sync/backup location", which would be a directory on some mounted filesystem to
which the bookmark data would be copied.  Bookmark storage would not be that
location exclusively, but dually in the normal location
~user/Library/Application\ Support/Camino as well.  On startup, Camino would
check the sync location first, and if not accessible would fall back to the
normal location.  On exit, Camino would again check for access to the sync
location and write the bookmarks their (if the location was not available at
startup, Camino should prompt the user before saving).

Comment 4

[Lane Roathe]

This is a great idea, one I would be extremely interested in. Should be easy
enough (hahaha) to grab the code that does this in the Mozilla browser.

As for use of the .Mac feature, I don't know anyone who uses it so I wonder how
truly useful it would be? I think the suggestion to have a choice between SFTP,
FTP, HTTP, HTTPS and a file location would be perfect. Not only would a file
location serve to allow .Mac integration but it would also allow SMB, AppleTalk
IP and other types of lan/internet storage use.

I think it would be very weird to have an OpenSource project require use of a
fee based service, or even to have a signification feature only work on such a
service.

PS: This feature really needs to be compatible with the Mozilla browser, moving
between them (I do a lot of web testing) is very frustrating because of the time
required to import & manually sync bookmarks. If this could be come a standard,
perhpas other browsers would adopt it.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mass-reassign of bugs still assigned to pinkerton to nobody; filter on "NoMoPinkBugsInCamino".