Roaming - Funding - Sync during runtime

VERIFIED WONTFIX

Status

Core Graveyard
Tracking
--
enhancement
VERIFIED WONTFIX
17 years ago
2 years ago

People

(Reporter: BenB, Assigned: BenB)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

17 years ago
This is part of bug 124026. It's a dumping-ground to discuss ideas and funding
of syncing roaming data like bookmarks, cookies, address books etc. during
runtime of the app, so that you can run 2 browsers at the same time using the
same data.

My personal assessment is that this is a lot of work. We will need to modify
each of the "datasources" specifically to allow that. I don't think, it's enough
to reload a file in a certain interval, because 2 versions might change at the
same time. I.e. you add a bookmark in one browser and at the same time add
another one in the other browser. Which file do we use now? So, we'd need to
break the data down into single items (like individual bookmarks) and sync that.
That's pretty hard, from what I am thinking atm. Something like that is probably
a few months of work, meaning x0000$. I don't think, we can raise the funding
for that.

To make matters worse, that work would be almost completely independant of bug
124029. That bug is completely different code and won't help at all with this bug.

Matthew Miller suggests to reload the bookmarks file at certain intervals for
that, we could use the code from bug 1242029, but I don't know, how that
approach could work at all. Matthew, how do you expect that to work, given the
complications noted above? Do you have some special circumstances, e.g. a master
copy, which is the only version ever modified, and all other browser just read?

Comment 1

17 years ago
Since there is no bug #1242029, I'm not quite sure what you're talking about. :)

I agree that coping with the case of simultaneous changes isn't completely
trivial -- that's why I put it higher on the chain in bug #124026. However, I
put it lower than the "true syncing" option, because the case where two changes
happen should be rare enough that it can be dealt with in a kind of clunky way.
In fact, this is *exactly* what Netscape 4.7x does -- if the bookmarks change on
disk, and you then make a local change, it pops up a dialog that says "Bookmarks
have changed on disk. Discard your changes and reload?"

I think the wording on the dialog should be change to "Keep your changes or keep
changes in file?" (or perhaps something even better than that), but the basic
idea is acceptible.

What Netscape 4.7x doesn't do is go the added step of actually checking the
on-disk file every now and then and reading it in automatically, but honestly, I
can't see why not. In fact, doing so is essential to reducing the number of
collisions.

Comment 2

17 years ago
Oh, bug #124029. :)

Hmmm, I think the description here is a little confusing. There's two separate
issues, one of which you've focused on here but isn't really relevant to what's
mentioned in the summary. :)

That is: the issue of running two browsers at the same time. Why do I say that
that's irrelevant? Because it's a problem no matter when you're copying
bookmarks -- you'll still run into it with startup/shutdown copying only. (Start
browser A; start browser B; change bookmarks A; change bookmarks B; shut down
browser A; shut down browser B. Doesn't even require a complicated situation.)

Because of that situation, your bug #124029 code already needs to have a simple
conflict-resolver, a la NS 4.7x's "Which file to keep, please?".

Once you've got that, this bug is basically just about calling your
check-and-copy function at scheduled intervals, not just at startup and
shutdown, and should in fact be pretty basic. Unless I'm missing something. :)

Also, while you're checking the remote files, you might as well add in bug
#78072 and check for external changes in the local file, because that makes
everything behave in a more-expected way. In fact, it might be easist to
conceptualize that as the first step to this one, and make it a dependency --
depending on how the actual code looks.

Updated

17 years ago
Blocks: 124026

Updated

17 years ago
No longer blocks: 124026

Updated

17 years ago
Depends on: 124026
(Assignee)

Comment 3

17 years ago
> the case where two changes happen should be rare enough

I am not sure about that. If I run 2 browsers at the some time, I might also add
bookmarks in each of them, not?

> if the bookmarks change on disk, and you then make a local change, it pops
> up a dialog that says "Bookmarks have changed on disk. Discard your
> changes and reload?"
> I think the wording on the dialog should be change to "Keep your changes
> or keep changes in file?" (or perhaps something even better than that),
> but the basic idea is acceptible.

I understand.

> That is: the issue of running two browsers at the same time. Why do I say
> that that's irrelevant? Because it's a problem no matter when you're copying
> bookmarks -- you'll still run into it with startup/shutdown copying only.
> (Start browser A; start browser B; change bookmarks A; change bookmarks B;
> shut down browser A; shut down browser B. Doesn't even require a complicated
> situation.)

The file on the server won't change unless there's a second browser running,
right? If I use the same profile at work and at home, "copy-newer" (as you
called it) (sync during startup) is completely sufficient. Unless you are
fiddling on the server, of course.

With bug 124029, you are plainly not allowed to run 2 browsers with the same
profile and change files in both, or you'll lose data.

> Because of that situation, your bug #124029 code already needs to have a
> simple conflict-resolver, a la NS 4.7x's "Which file to keep, please?".
> Once you've got that, this bug is basically just about calling your
> check-and-copy function at scheduled intervals, not just at startup and
> shutdown, and should in fact be pretty basic. Unless I'm missing something. :)

In bug 124029, you compare 2 files: the local bookmarks.html and the one on the
server. With bug 78072, you compare the local file with your in-memory data.
Maybe we'll generalize all 3 copies, but I am not sure.

Comment 4

17 years ago
> I am not sure about that. If I run 2 browsers at the some time, I might also
> add bookmarks in each of them, not?

You might. But it's more likely you're at one place and just happened to leave a
brower running at another. Making a system designed for many people to share the
same bookmarks file -- or better yet, a subset thereof -- would be very very far
down my $$$$ pyramid. :)

Anyway, the more often you check and copy-newer, the lower the chance of a
clash. Just doing it at startup/shutdown makes it quite likely, for example, the
very likely case where I run my browser at home and add bookmarks, and then
forget to close it before going to work.



> With bug 124029, you are plainly not allowed to run 2 browsers with the same    
> profile and change files in both, or you'll lose data.     

As I mentioned, NS 4.7x includes rudimentary detection for this situation, and
presents a dialog allowing you to choose which to keep. So if you're not going
to do that, it's not really on the level of the old version. And if you are,
it's not much harder to do this. :)

Comment 5

17 years ago
I always have Mozilla running on 2 or 3 computers simultaneously, but I never
actively use more than one at a time. A solution that would have a sync code
(that would pop up a question if a clash is detected) with a UI to force sync
and a pref to specify how often you want a sync to happen on its own would make
me completely happy. If sync would also look at the local files as well as at
the remote location for changes, that would be a nice added bonus.
Is there a generalized Mozilla bounty program?  Aside from the code-rot problem
it could be quite interesting.  The street performer protocol could be implemented:

http://www.counterpane.com/street_performer.html

I'm sure there are plenty of good high-school coders who would be better off
hacking after school than flipping burgers.

Code-rot could kill it though.
(Assignee)

Comment 7

17 years ago
> Is there a generalized Mozilla bounty program?

No. I don't know of any precendent for this. I hope that Beonex can offer this
service, but admittedly with a strong bias towards me as programmer :-).

> I'm sure there are plenty of good high-school coders who would be better off
> hacking after school than flipping burgers.

Sure. But are there plenty of people willing to spend money? I hope so, because
I see it as the future of open-source.
Status: NEW → ASSIGNED
(Assignee)

Updated

17 years ago
Target Milestone: --- → mozilla1.1
(Assignee)

Updated

17 years ago
Target Milestone: mozilla1.1 → Future
(Assignee)

Comment 8

14 years ago
This was a funding bug, and I don't see significant funding for this feature (in
contrast to bug 124029), so closing as WONTFIX.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
(In reply to comment #8)
> This was a funding bug, and I don't see significant funding for this feature (in
> contrast to bug 124029), so closing as WONTFIX.

We typically don't resolve bugs WONTFIX because there hasn't been any activity
on them if the ideas still has merit.

Are you saying that bug 124029 covers this issue anyway?  I see the first
comment in bug 124029 references bug 124026, which this is about.
(Assignee)

Comment 10

14 years ago
This was a *funding* bug, only to be resolved when enough *funding* *for me*
arrives to implement this. Given how long I *actually* needed for bug 129029 (in
contrast to how much I guessed or got money for) and that this bug is *much*
more work, we'd need to be roughly in the $30000 range somewhere. I got offers
of no more than §300 IIRC, which is missing the target quite a bit ;-). So, I
don't see any hope of resolving this, unless somebody with a really thick pocket
shows up. Sorry.
(Assignee)

Comment 11

14 years ago
BTW: I thank you all for your kind support and generosity.
Ah, I didn't realize this bug was intended just for you (Ben).  In theory I'd
rather see this assigned to nobody instead of WONTFIX, but I admit that funding
through bugzilla bugs is not in a workable state.

Verifying.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 13

14 years ago
Compare bug 245985.

Comment 14

14 years ago
> The file on the server won't change unless there's a second browser running,
> right? If I use the same profile at work and at home, "copy-newer" (as you
> called it) (sync during startup) is completely sufficient. Unless you are
> fiddling on the server, of course.

Ben, I don't agree on this. I used the old 4.x roaming a lot and it's easy to
get problems here: e.g. you shutdown your browser at work, but due to a crash or
network problem the files can't be uploaded (or even some of them and some not). 
Then you get home and have no chance to download your new files (or all of
them). The next day at work the current solution will download your home files
from the evening before. That means that the files which couldn't be uploaded
the day before will get lost, because they are older than the files on the
roaming server.
(Assignee)

Comment 15

14 years ago
Of course, if you leave work, you need to upload the files. If the browser
crashes, you have to restart and close. I tried hard to detect problems with
upload, and if any are found, the progress dialog should report them (instead of
closing automatically).

> That means that the files which couldn't be uploaded
> the day before will get lost, because they are older than the files on the
> roaming server.

No, I wrote code so that this case should be detected when you start the browser
at work. Please try it.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.