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?

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.

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.

> 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.

> 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. :)

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.

> 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.

This was a funding bug, and I don't see significant funding for this feature (in contrast to bug 124029), so closing as 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.

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.

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.

Compare bug 245985.

> 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.

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.