Is "roaming access" (as in Netscape Communicator 4.x) planned to be included in Mozilla? Roaming access = user profile (bookmarks/cookies/history/etc) is stored on a central server. Client synchronizes local profile with the profile on the server to be able to have same profile regardsless where the user is localized.

saska@acc.umu.se, this is a great question to ask on the Newsgroups. (For more information, see http://www.mozilla.org and "Community".) I'm not (personally) aware of any plans to implement it on 5.x. Now, if *you'd* like to implement it...

elig, why is this won't fix??? Reopening.

Rationale: Saska had plans to work on this. Maybe, he didn't assign it to him, because he wasn't sure, if he really will implement this.

My first opening of this bug maybe didn't make it clear that I am willing to look into this, but I'm currently only investigating it since I'm not sure if I'm capable of implementing this. I'll assign this to myself, but anyone is free to take over it if they feel appropriate since I don't expect to be able to contribute much for some time ahead.

see also bug #17817, which is a feature suggestion for a smarter version of this.

sorry, typo. that should be bug #17917

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

What about including support for FNS/NIS+ (Solaris/Linux) (this was rfe/bug 20684)... ?

Another idea: What about an #include-like directive on the prefs which says get other info from LDAP/X500/NIS/NIS+ ? This would allow per-group settings...

How about an option to use the Application Configuration Access Protocol (ACAP), in addition to HTTP and LDAP, to store the configuration information? This protocol is designed for exactly this purpose. More info on ACAP is here: http://asg.web.cmu.edu/acap

yes, there was a (positive) discussion about ACAP recently on n.p.m.mail-news.

adding myself to CC. I worked with (though not on) the 4.x roaming, and I have had some experience with roaming-type-stuff. I really like the idea of using ACAP for this. LDAP (4.x's preferred roaming store) is just not suitable for this.

Putting on helpwanted keyword radar. At this time a net community engineer would need to implement this.

Saska, could you please update the state? No roaming in Mozilla would be a real bummer. If we want to lobby for a implementation by Netscape, we will have to do that now. But, of course, it would be nicer, if you could implement it :). I'm sure, Netscape employees would help you, where needed.

This is definitely one of the most interesting projects, but it doesn't help when there's a lack of time. There have been too much changes in my personal life to even have a chance to give this a shot. I moved to another country and have a full time job now :/. But I have managed to have a look at the ACAP protocol. There is a free test server at "acap.andrew.cmu.edu" 674 where you can authenticate using the Anonymous SASL Mechanism. ('a authenticate "anonymous" "test"') ACAP looks like the right way to go. (I changed email btw.)

Saska, can you give a timeline for implementing this? M17 (due in ~2,5 months) is planned to be feature complete (if that still stands).

Even if this doesn't get in the final release (ACAP, LDAP, HTTP or not), it would be useful to consider other ways to make roaming more easily possible in a LAN/WAN environment. Currently 4.x on Win32 is rather unfriendly to this, as you can't merely throw the user profiles on a network drive and pick up and go to another computer and easily get them, since nsreg.dat must contain the profile data, and it can't be moved from the system's local Windows directory. There are workarounds for this, but they're rather clumsy and can be a deterrent on large deployments. I fear that Mozilla is going down the same path, given what appears to be stored in mozregistry.dat. The goal would be to create a better way to allow network roaming, perhaps possibly storing mozregistry.dat, or at least its profile location data, within the user profile directories. If this should be branched into a different bug number, someone holler and I'll open a new one. This request is similar, but not identical, to bug 9556, though the fix may be the same.

khecht, yes, this is the same goal, but a completely different method and thus bug/feature. Please file a new bug and post the number here.

Ben, I'm afraid I can't give a timeline. Not under these circumstances. But I will look at it once more and see if I could get started with it (though it might become quite time consuming). Help still wanted!

Saska, what kind of help do you need? Maybe we can break this bug up into several others (see below), so the work is spread across several developers to speed up implementation. Maybe - UI - Backend - Protocol Hanlders - ACAP ? (Other sugegstions welcome.) What part(s) do you want? If you need informations, e.g. what is the best place in the code to plug in your changes, Mozilla developers (including Netscape employees) will be happy to help you (fast hopefully). If not, tell me.

Ops, the bug break up: We can turn this bug into a "tracking bug", i.e. its purpose turns into solely holding dependencies to other bugs.

LAN/WAN comments from above branched off into bug 31732.

Ben, that sounds good. The two main parts are accessing the preferences in mozilla and the acap protocol. I hope it will be sufficient to implement only a subset of the acap protocol (only the parts mozilla needs), without breaking protocol compliance of course. And as you said, pointers to appropriate places to "hook" the code probably would increase the chance of someone getting started with this.. This RFE still needs someone who has some time..

OK, turning this bug into a tracking bug. M17. saska, asking module owners for the big picture (if you can't find docs, which is likely :-( ) is a good start. They can also tell you owners of more specific parts/topics. See <http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser> and <http://www.mozilla.org/owners.html> for module owners, e.g. gagan@netscape.com for Necko (or netlib or network library or netwerk) and matt@netscape.com for Preferences UI. Assign this bug to nobody@mozilla.org, if you want to give it away. You're still free to help and/or take one of the new subparts. I'm also officially founding the "roaming access lobby association" :-). Vote for this bug and tell your friends about it, if you think, it is important.

Reassigning to nobody@mozilla.org for now. Not giving up though.

Rather than implementing ACAP, an easier way would be to just subclass (or even extend) nsIFile to allow interaction with remote files over HTTP and/or FTP. Then stuff like bookmark files and .newsrc files could simply be specified as complete URLs. The only parts of the core code, then, which would require much work would be places where the callers are assuming that nsIFile will return at disk rather than network speeds.

It depends on how you implement it. The problem is that network operations are generally asynchronous, and nsIFile operations are generally sychronous. Most consumers of nsIFile objects make the assumption that calling into nsIFile will return their data immediately, without locking up the browser.

I think that as this feature is implemented, it's important to maintain flexibility for the user community. This means that while ACAP is a good protocol to use which is promising; HTTP is easy to implement and hopefully can be included in the final release (like 4.5x is now w/ LDAP and HTTP). I'd like to make a plea to the implementors to allow roaming via HTTPS (Secure HTTP) -- this is broken in 4.5x.

Certainly, the design phase of this should certainly result in something that accomodates any number of underlying technologies available now, e.g., ACAP, LDAP, local store, and HTTP, and be expandable to include whatever might come around in the future. An abstraction layer that mozilla interacts with (an interface, the associate IDL) should be able to achieve this flexibility if done correctly.

It would be really great if you could set an option in the config files so that a remote profile has to be loaded upon starting mozilla. Useful in computer labs or places where many users share several computers. The IMSP protocol would be another possible implementation, at least for the mail/addressbook.

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

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

I note that Carnegie Mellon just made a public release of an ACAP server with complete functionality on comp.mail.imap. ACAP really is a nice protocol, and it would be great to have Mozilla support it, if it comes down to a choice of technologies to use in order to make this happen.

the problem is not choosing a technology, it's getting the resources to add this to mozilla :( But I like ACAP, and CMU has been producing this server for a few years now, I think it's pretty good.

Taking QA contact since it is currently nobody@mozilla.org.

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

People have tossed around various ideas on this problem, but I think at the minimum Mozilla should have the same roaming capabilities as Netscape 4.7x. At the minimum, LDAP and HTTP should be supported protocols with the following stored items: bookmarks, cookies, mail filters, address book, user preferences, history, Java security, certificates and private keys. Other protocols and stored items could be supported, but I've already seen a number of people complaining about the lack of what's already implemented in Netscape. Assuming this won't make it into an initial release of either Mozilla and Netscape 6, what can we do to get this moved to the top of the heap for the next go 'round. Is it just a matter of voting?

it's a matter of finding (or funding) the right people to work on the problem. it's a big problem, would probably require 2-3 engineers a few months to get it right

This would be great to have by mozilla1.0. Setting the Milestone for nobody since he's such a busy guy to do it himself. :)

David, I think, nobody prefers to have all his bugs sat to Milestone "---". :-)

Yes, in fact please don't change the milestone or priority fields on a bug unless it's assigned to you to fix. Thanks for adding the mozilla1.0 keyword to keep this bug on the radar. The target milestone gets set when we find someone to sign up for this work: that way we can query for keyword contains mozilla1.0 and milestone != mozilla1.0 to find unscheduled work.

yes, and given the magnitude of this feature and the fact that nobody is working on it, I think the chances of this being fixed by mozilla 1.0 are about 0.

I think that ACAP is a bad idea because: - it is not as spread nor standardized as HTTP or LDAP; - c'mon folks the code DOES exits somewhere in the NS4.x base and it seems like if you want to see this feature at all, we should at least start from that. - by looking at the "how acap compares to..." document (http://asg.web.cmu.edu/acap/white-papers/acap-vs-others.html), the designers of acap didn't have a very profound understanding of the LDAP or HTTP approaches. some examples taken from the acap vs ldap: "Directory servers don't have per-user quotas for control of option storage space; ACAP does." Well that's exactly one of the uses of ldap schema attribute constraints. - "In other words, if a client were to have a need for a non-pre-defined namespace or storagespace on a server, the server's administrator would have to re-define a field in the database." Get around that "problem" with a smart and flexible schema (hey, it worked for NS4)!! - "Rather than having to know something about the server's view of the universe, the option space in ACAP is free and open to unforseen uses (allowing for namespace conventions)." Same thing. As for HTTP, just go see http://www.klomp.org/mod_roaming/ Again IT WORKED BEFORE, why not start from there?

BTW, if netscape is willing to commit the roaming code for 4 (or is it already in the cvs?). i'm willing to give it a look, and report...

<http://www.syncml.org>

How can we at least start defining the requirements for this? Should a new module be started? We should at least be able to define the interfaces to a roaming modules regardless of whether we can actually get code from Netscape for the old support. Ideally, this should be a new ground up implementation that would frontend several "pluggable" storage and retrieval mechanisms (at the minimum HTTP and LDAP to give the functionality of Netscape 4.x). In fact, I can really only think of two valid calls to the module: store() and retrieve(). Assuming that everything is put together properly, it should make it easy for additional storage mechanisms (syncml, etc.) to be added at a later date.

Would it be possible to allow roaming profiles download through proxy/firewall system ? This is a major problem I encounter when travelling and trying to get my profile from internet cafe systems... Also how about download of profiles using https ???

Let's move the general back-and-forth to the netscape.public.mozilla.general newsgroup so that we get more visibility for this. If you post a new messgae, try to reference the bug number in case anyone is interested in the history.

I think XBEL is the shapeliest solution http://pyxml.sourceforge.net/topics/xbel/

So there seems to be a lot of folks interested in seeing "roaming" happen, yet I can not find any actual activity being done to manifest this feature. I've searched through the roadmaps, module owners, projects, alternative projects and newsgroups I would be interested in helping out in making roaming happen with what limited time and knowledge about Mozilla I have. But would like to find others who are also interested but might have a clue as to how this would fit into the existing Mozilla structure. Is there a place to discuss such things? Is there anyone out there who is familiar enough with Mozilla that could give some pointers or could architect the overall design? Then others could start working on it... Maybe do it on a tiered plan where we can do something quick and simple and get it out, but with a roadmap to something more sophisticated and robust. If there is no one already focused on pulling this together, I would be glad to at least try to coordinate an effort... For

sure - everyone is willing to help, but nobody is willing to start coding. That's been the state of this for almost 2 years now :)

For some related but not quite so general work, see bug 18043.

Everything related to "romaing" support should be part of 17048. Additionally, these discussions should happen in the newsgroups. The thing that has messed this item up is that everyone want sto use something other than what is necessary. See the previous info as to why ACAP should not be considered. We should start with LDAP as Netscape already has code for it. Please move this discussion to the netscape.public.mozilla.prefs newsgroups so we can talk about it without cluttering the tracker. TIA.

netscape has barely any code for ldap. we should come up with an abstract roaming layer, and then build ldap, acap, and http implementations of each one.

Added to CC

I agree with Alec completely, that is the optimal way to go about it.

There has been some pre-implementation brainstorming a month or so ago in the .prefs newsgroup; folks interested in this bug may wish to check that out.

Assigning to self for future work.

As you consider different protocol, Think about adding the jabber protocol to the list. Jabber started as an XML based instant messaging protocol but has growing into a generic XML routing protocol. I think it would be perfect for this. It has the ability to store XML information public and privately on a jabber server. There is even an avatar enhancement proposal going on in it now. You could show a users avatar in the profile :) Another thing to consider about it is there is already Jabberzilla in the works which is a mozilla based IM client of jabber. It is over at mozdev.

Another thing to consider about using jabber is the dotGNU project is considering using it as well. The dotGNU project is: DotGNU will be a complete replacement for the .NET strategy - it will not be a Free Software implementation of .NET. While .NET has some very sound ideas, problems arise with its implementation, especially with the Authentication/Authorization systems which are centralized to Microsoft, and with Microsoft's vision for "web services". Roaming seems to me like it is a very good first step "web service".

individual protocols should be listed in new bugs. This bug is just for the architectural design of roaming, with pluggable protocols

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

A very simple way to satisfy about 80% of the needs of roaming-profile users is to make mozilla aware of changes on disk. That way one can effectively implement shared bookmarks with a little script that copies bookmarks over the network. Right now you can *remove* the bookmark file while mozilla is running, and mozilla will take no notice. It's (hopefully) very simple to do a: stat(bookmarks.html) if(bookmarks has changed) reload bookmarks on a regular basis (i.e. at the end of the main event loop). It would also be necessary for Mozilla to write out bookmark changes as soon as they are made (not sure if it does this already...). WindowMaker does this with its menus, and it's quite nice.

Good point; that should probably be RFE'd as a separate bug.

marking nsenterprise-; will be reevaluated for nsenterprise in future release.

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

For those who are interested: Ben's suggestion is already in bugzilla: #78072

sorry, let me make that a link: bug #78072

and when I say "Ben", I mean "Bob", in comment 63. Sorry about that. Okay, enough spam from me.

With the recent focus on "mobility" I don't see that awareness of changes in one file helps much, if I understand how Bob means that 80 percent of the need would be handled by this one change. I also don't know that I'd like the impact on a file server that would result--again, provided I understand Bob's meaning. Centralizing mail would be important for organizations using NS as the mail client, and this is a case where roaming profiles would be the answer. Perhaps this is in the 20 percent uncovered by Bob's suggestion. ;-)

Scott, please find a new home for these bugs. Thx!

what about DAV for roaming ? (http://www.webdav.org) ... today i played with the DAV module in the apache2 dist. it is great. it would be easy (for the admins like me) to get roaming running because a lot of server software is starting dav support. it would not require people to install a complete new set of servers like acap or stuff like that. the second importand thing ist that it uses no special tcp ports - in times where firewalls are implemented every day it easiely could happen that people cannot access thier profiles. the files would even be accessable for admin-scripts for example if someone would like to do a profile-value change on an >1000 userbase. therefor cool admin interfaces - masterconsoles can be build with remote access- and the arguments for solutions like exchange are vanishing i am no coder but an admin with php/apache skills - we use a "self-build",very messy roaming for netscape 4.7 (via samba macros) for a ~900 userbase. since i want to migrate to mozilla (if roaming works) i would help in terms of testing and stuff if if someone is interested.

Shouldn't this bug be marked as dependent on bug 66259?

Aleksander -- they don't really seem related to me.

Maybe Aleksander is thinking of Windows 'roaming profiles' which involves copying an obscene amount of data from a server to a local location when you login to a windows network machine. The profile would have to be movable for that. This feature lets you avoid those kinds of kludges, and could work anywhere on the net.

Why not just use the stuff from 4.x instead of suggesting (and not implementing) all sorts of grand schemes; jabber, DAV, whatnot; it worked in 4.x and there are numerous (proven) ways of implementing it on the server side. Of course a new module that can do all sorts of magic would be nice but just re-introducing the 4.x roaming would be sufficient for a lot of users. Where is that source code? Did it never get released from the old netscape codebase? I cannot find it in any Maozilla source tree.

there's no way we're ever going to ressurect the 4.x roaming code. mozilla has diverged too much.. sorry.

------- Additional Comments From alecf@netscape.com 2002-02-05 17:36 ------- there's no way we're ever going to ressurect the 4.x roaming code. mozilla has diverged too much.. sorry. Sorry to flame, but it's justified here. You guys have been dragging your feet on this issue for years now. This should not be that hard. In the mean time, most of your potential user base has been forced to IE because Mozilla/NS6 still has only a fraction of the capability of NS4. We don't WANT fancy be-all and end-all solutions that are too late to do any good - we just want it to WORK LIKE IT DID! The developers have consistently refused to even consider using the 4.x code, preferring grandiose visions while simultaneously complaining there aren't enough people to implement them. Finally, at least at a superficial level, it appears that roaming functionality should be relatively contained (I admit to not having looked at the code, and not being a good coder in any case.) Based simply on what it does, it doesn't appear to be deeply intertwined with the 4.x codebase. It sure looks to most of us as if this is just something the NS6/Mozilla team does not care about and has not taken seriously in the entire 2+ years this bug has existed. Your comment that "the code has diverged too much" in interesting, but if you have actually looked at the effort required to move it, you are the first in the history of this bug - a read through the comments suggests that no one has ever bothered to scope the effort required to implement the 4.x functionality. We are witnessing the abject failure of the open source development model. With every passing day, it seems Mozilla progresses on its path to elegance, persnickety geekoid perfection, and totally irrelevancy.

> The developers have consistently refused to even consider using the 4.x code, > preferring grandiose visions while simultaneously complaining there aren't > enough people to implement them. Have you ever looked at the 4.x code, and then looked at the Mozilla code? I don't know anybody who has ever worked on Mozilla and who proposes to resurrect the 4.x code, other than maybe as cheatsheet. There are not only grandiose visions proposed, but also alternatives that are easier to implement. It is fine that grandiose visions are proposed, we need them to consider them. That doesn't mean that we consider them /necessary/ to fix this bug or that we get sidetracked by these ideas. > It sure looks to most of us as if this is just something the NS6/Mozilla > team does not care about and has not taken seriously in the entire 2+ years > this bug has existed. That's right. Obviously, nobody has had enough interest in it to impleemnt it. Netscape started some effort some time ago, but I don't know about any code coming out of it. I'm not happy about it either, but I have other priorities myself. So, what? Sue us? > We are witnessing the abject failure of the open source development model. No. Open-Source means that *you* can go in and implement it, if you need it. Or pay somebody <http://www.beonex.com/dev> to do it. Open-source is what allows you to talk to the developers at all and watch the (non-existant, granted) progress.

I am in agreement with dub. This is ridiculous! One of the main selling points of using an NS browser was the roaming access. I work for a college and this feature is invaluable to our community. I work for a college and this feature is invaluble to our community. We are currently fighting a losing battle with our community, who need to use IE or NS6xx for certain applications. We cannot keep telling them to use NS 4.7 and since NS 6xx does not have roaming, we cannot use that as a reason why they should use NS instead of IE, which comes neatly packaged with their PC. Roaming is an excellent feature and I do not know why it cannot be applied to NS6xx as it was in 4.7 -- I really don't care about any more new features on it -- if I have the same exact features that are in 4.7, I would be a very happy camper. How difficult can this be? I am not a coder in this open source environment, but if the Mozilla group works with Netscape, why can't this be done? Is it due to a lack of interest -- which it should not be, as IE does not have this feature at all!, or not enough folks to work on it? I have never posted here before, but I have been tracking this bug very closely for the last year or so, and I am quite disappointed by the brief little statement by Alec Flett...Trust me, we have 20,000+ users here on campus and they will not be very happy if they lose roaming. And we will be forced to go the MS route with IE as our standard browser.

Dub's being overly harsh (I don't think this is important enough to signify The End Of Open Source, and I don't see why people would go to IE over this issue when IE doesn't have any type of Roaming Access-functionality either), but his frustration over this is something many of us share. Correct me if I'm wrong, but it looks like the Netscape folks are refusing to release the 4.x roaming module source, which doesn't make much sense. When Alec says the code has diverged too much, I have a sneaking feeling he's referring to the LDAP portion of Roaming Access, which Netscape always seemed to think would be the main way of implementing it. But I don't know anyone who uses it in LDAP mode (who even runs Netscape's web server anymore?); the preferred use by everyone I've ever talked to is through HTTP with the Apache mod_roaming module on the server side. How 4.x-specific could the HTTP part possibly be? All it does is compare the dates of two files, does a write test, and then downloads or uploads through HTTP. This seems like fairly lizard-brain stuff to me. Of course if I'm wrong, it'd be easy to prove it by releasing the code.

dub@conservor.com hit the nail right on the head: This is a *very useful* capability that was available in Netscape 4.x two years ago, that still isn't available in Mozilla/NS6, and, as far as I can tell, is likely to never be available in Mozilla/NS6. Which is really a shame, since, as a useful capability that isn't available in IE, this feature alone could be enough to convince some people to switch to Mozilla. (I know that the *lack* of this feature alone is enough to convince several people in our group to stick with NS4 instead of upgrading to Mozilla or NS6.) The resistance or lack of interest is baffling. It seems like one of the easier features to implement, and the utility should be obvious to anyone who uses more than one computer for web browsing. It may not be as sexy as some of the other development, but if you want more people to use Mozilla, implementing roaming would likely do more toward this goal (relative to the time invested) than almost any other effort on the slate.

just to add some oil to the fire. one of the main reasons i am still using NS 4.7, and haven't switched to IE is because of its roaming capabilities. if MS implements roaming i will drop NS in a split second. i agree with sluggo that the roaming module can't be anything too difficult to implement. i am sure there's already open source sync software via HTTP available if it is soo hard to integrate the code from from 4.7. that's my $0.02 worth :)

I don't have a lot constructive to add to what's already been said, except that to those who are saying IE doesn't have this functionality you are correct, BUT, MSN Explorer that comes with WinXP has web-based bookmark storage functionality. I've not used it myself but some of my friends swear by it. As I workaround until the mozilla developers get around to working on this (assuming they ever do), I've been toying with the idea of writing a sidebar that would be generated from CGI on a web server, which would allow you to work with remote bookmarks that way.. Presumably you would add this sidebar to any netscape 6.x + or mozilla browser you use and once you login your bookmarks are right there. I'm fully capable of doing the server side of it (in perl), but I haven't looked deep enough into XUL to see how difficult the sidebar piece of it would be. If anyone is interested in getting a project together for this e-mail me and we'll see what we can do.

Yep, roaming access is a terribly useful feature that I still can't live without. I browse equally from two workstations at home, from work, and from my laptop. Roaming access was a godsend for keeping my huge store of bookmarks in sync. I still keep 4.7 around to keep everything in sync, then export the bookmarks to Mozilla. It's a pain, but worth it.

Stop whining. Netscape usually doesn't base such decisions on bugzilla. Pratically everybody else is working in their free time. So, whom are you talking to? Are you telling me that I should spend *my* free time to implement the feature *you* want? Do something. Fund money. If you are willing to put up more than 50 US-$, mail me. If you administer lots of clients, your organization could fund 1$ or more per client. If that adds up to enough money, I'll organize something. Remember that you got Mozilla for free so far. If you are not willing to put up money and not willing to help coding, please save us with your comments. This bug has 104 votes, which means that - we already know it is a most-wanted feature - you spam a lot of people by commenting here.

The following assumes this bug suffers from a lack of specification: HTTP roaming access doesn't have enough complexity to be worth reviewing the Netscape code. See here: http://help.netscape.com/products/client/communicator/manual_roaming2.html If you want server-side example code, try this: http://www.klomp.org/mod_roaming/ It implements the MOVE command that netscape used for safe writes. You don't even have to have MOVE if you don't care about safe writes. The real work here is factoring out which parts of the Mozilla profile need to be stored on the server. Bookmarks? Cookies? Prefs? Certs? Skins? MailNews too? I don't know, I'm asking. Assuming more than just bookmarks, does anyone know what format netscape used? Was there an archive format for the server storage or are there several files per user? I'd suggest getting HTTP-based profiles working with straight puts, then add in the safe writes, then worry about LDAP or ACAP or WEBDAV later. A really generous hacker would stub in generic read and write functions in the beginning so it could be easily modular later. The read from the server would just have to happen really early in Mozilla startup, and the write really late in exit, right? What will that break, if anything? Did Netscape let you read and write from the server at arbitrary times? Maybe if this bug gets a little better specified it'll be easier to divvy up tasks and get something working. To the people afraid of the death of Open Source, the bazzar doesn't work for step 1, or so the theory goes. Mozilla's real collaboration problem is code-rot, but that's a separate issue.

The netscape communicator implementation is actually pretty awful -- it would read once right at startup, and write right before exiting. The entire bookmark file is stored on the remote server as one file (same with cookies, etc.) and the whole thing is sent if the dates don't match. Mozilla bug #78072 isn't necessarily a dependency of this bug, but having that work would take a lot of pressure off of this one -- if the bookmarks file changes on disk, mozilla should transparently reload it. That way, until roaming is fully-integrated in Mozilla, it'd be easy for a simple, separate third-party program to do the work.

Everybody go vote for bug #78072 (make mozilla aware of bookmark changes on disk). This would make much of this discussion moot since the "profile" could be handled by third parties with a very simple script using scp, or nfs. (i.e. two copies of mozilla running on two different machines with your home dir mounted wouldn't clobber the bookmark file on each other) bug #78072 could be extended to cover history, preferences, etc. The NS4.x solution of putting everything on a central server, and pushing updates upon quitting...just isn't very elegant.

The NS4 solution is very elegant - it is a a major reason that roaming profiles worked so well. It would be a dream to share a single profile across OSX, Solaris, Be, Linux, and Win32, even if all of those don't support the same shared file access mechanisms, and are *not on the same physical network*. That was a huge key: web-based sharing would allowa dial-up users to access profiles from home or on the road, or broadband users to load their moz profile from their home server at work. Relying on the OS file-sharing mechanisms runs counter to the cross-platform applicability of the feature.

There you go again with making the roaming all spiffy and elegant, when what most people want is just *the old functionality*. Never mind if it's clunky. The transfer stuff could be taken care of by an external script easily, if someone could explain (decode heaps of C++ code) how to handle e.g. platform-specific paths, and any other cross-platform issues. Note that it's the HTTP based roaming most people seem to want not the LDAP one.

For those in the "it should be easy to port the 4.x code" camp the following might give you a useful starting point: http://lxr.mozilla.org/classic/search?string=li.protocol

People: This is NOT A PRIORITY right now.. it doesn't mean we don't agree that it's cool or what have you, it just means there are other things that are taking a higher priority. So you can stop your whining that people are "dragging their feet" and you can stop with the "how hard can this be" - if it's really that easy, go implement it yourself... nobody is stopping you. It's sad that open source's original goal of "if you want an improvement, you submit a patch" has degenerated into "if you want an improvement, you berate and insult people with the expectation that they will cower and bow to your wishes"

and sluggo: your "sneaking feeling" that I'm referring to LDAP code, or that Netscape is "refusing to release code" is utter BUNK. I'm being totally honest here - no hidden motives. Let's end the x-files-style conspiracy theory right there. - the libpref backend which handles roaming prefs has DIVERGED TOO MUCH - there is no way to bring the code from 4.x and drop it into libpref. it would actuallyt take less time to write it from scratch - a significant chunk of roaming involved a UI for managing roaming settings, logging into a roaming server, profile download progress, etc.. 4.x didn't even have XUL, so we'd have to write that from scratch - other modules such as bookmarks and history have been completely rewritten for mozilla - so we would also have to write that from scratch - 4.x handled roaming by labelling certain profiles as roaming profiles - all the profile code in mozilla is brand new, so we'd have to write the roaming-profile management from scratch. And so you see, it isn't as easy as people are making it out to be. 99% of the above code is STILL available on the mozilla classic branch - and I welcome ANYONE to even attempt to "migrate it from 4.x" - you can post your patches here.

I'm not the right owner for this. Reassigning to nobody@mozilla.org.

Following up on #92 if anybody does want to dig into the old code, I think one file you might be interested in is here: http://lxr.mozilla.org/classic/source/modules/libpref/src/prefapi.c On the other hand, what areas of the current code base would need to be touched to implement something similar?

I just told Ben Bucksch that I'll put forth $1,000 US towards funding a developer. All of you that are foaming at the mouth and critiziing Alec can put your money where your mouth is and contact Ben about contributing as well. If we all start coughing up some money instead of griping, even if it's as little as $50 per person, we could be in roaming profile bliss within several months. Considering that this bug has 102 votes (minus me) that's a potential $5100 + $1000 from me to fund someone to work on this. Please take the discussion to the newsgroups if you still feel like complaining.

Matt, this sounds very cool. I'll happily add some cash in to the development as well. But since there are so many methods on the table as to how to actually store & retrieve the profiles, shouldn't we narrow this down? I think this bug should become a meta bug, tracking all the potential methods to actually do this, and then we can figure out which one(s) we want to fund. That would give us (and the developer) a better sense of the cost & time involved. And a formal spec will make sure we're all in agreement on what we're paying for. - Adam

The best course of action to start is something compatible with existing roaming servers like mod_roaming. That'd be immediately useful, and would allow a mixed environment with Moz/NS6 and NS4.x clients during a transition. The one addition I'd like to see is just the ability to use SSL/TLS (https) for the connection. I never did grok why they was left out. I've contacted Ben with my 'pledge'. Now - perhaps this effort should be taken to a mailing list or something of the sort for coordination without abusing Bugzilla? -MZ

Adam- we should probably take any discussion of implementation details to bug 31763 and I should get back to work on bug 31764.

Thank you Matt Perry! I filed bug 124026 for funding questions. If any concrete (technical) implementation supposals with enough funding support creep up there, I will file more bugs and reference them here, so you can ignore that bug, if you are not interested in the funding.

Roaming should support IPC (inter-process communication) if bug Bug #68702 is landed. Then it is possible to use custom solutions for the saving process.

Bug 124029.

I'm interested in this as well, but is *compatibility* with NS4's roaming support really required, or just *coexistence*? For example, I'd like to be able to continue to use just one HTTP mod_roaming server for both NS4 and Moz/NS6 users as I transition them, but I have no need to have users move their actual profile from NS4 to Moz/NS6 and back. I'd be happy to just have HTTP roaming at all in NS6, so if Moz/NS6 used different files on the HTTP roaming server (and therefore NS4 would ignore those files) and used a different format (encrypted or not) in those files, I'd be happy. I figure one-time conversion of profiles from NS4 to Moz/NS6 can be done by downloading the profile in NS4, disabling roaming (so the profile stays local), upgrade to NS6, then re-enable roaming and push the new stuff up to the server. I'd even be happy to live without SSL support (I obviously don't use it now for NS4 roaming). Similarly to others here, my company will be happy to pledge $2000 US towards getting this done (since we unfortunately don't have the skills and time to implement this ourselves).

Hi, I have been fooling around a bit with a perl-skript. I had not so much time to get much done, because I have exams at uni, but I think it should be possible to get the basic http-roaming working quite easily. So if anyone with perl-knowledge wants to help, its welcome. I hope I can get some spare time in the near future and get a working prototype out. Greetinx Philipp Kolmann philipp@kolmann.at PS: Don't assign this but to me, I just want to do some testing, if it is possible.

Here are just my $.02 ... My approach to software development is K.I.S.S. "keep it simple, stupid" ... The way I see this, all the grand schemes proposed seem perfect, but it would take a lot of time (=money) to develop. Instead, the way I see this, roaming profiles could be implemented effortlessly with just these changes: On the "profile manager" add an option (checkbox) titled "Use remote profile" when this option is checked, a text entry box (single line) would show up, where the user might enter the "remote location" of their user profile, as an ftp url. ftp://billsbrowser:hereallylikesmozillabuthatestorecognizeit@ftp.microsoft.com And that's it!. On proceeding, Netscape 6.x would just show a dialog like "retrieving user profile". The whole directory would be copied to the temp dir, and when the user exits the browser, the data would be copied back from the local temp dir to the remote dir (ftp transfer). So, in the end, the user only has to: 1) Open Netscape 6.x via the "Profile Manager" icon. 2) Click on the "use remote profile" check box (the status of this and the text of the last used url, sans passwords, would be saved locally) 3) Use the browser with their remote data. 4) have the data updated on the remote server when the user exits the browser. Advantages of this approach: 1) "User profile" server can be ANY standards-compliant ftp server. 2) Any user with a remote hosting account can access their bookmarks file and preferences from anywhere with a Netscape 6.x and mozilla installed. To make this work better on low-bandwidth (=dial up) connections, a GLOBAL setting on the Netscape/Mozilla preferences, saved to local hard disk, possibly under "Advanced->Remote Profiles" would let the user specify, via a simple list with check boxes, what items are retrieved/stored from/to the remote server. So, a user on dial-up from africa might want to login to his ftp server, but have only the bookmarks.html transferred to the local system, not the certificates etc. The idea here is giving the end user total control of what parts of the remote profiles he wants stored. Users on narrowband might want to check only "bookmarks" while others roaming on an enterprise LAN might want to have their skins/certificates/sidebar_preferences etc retrieved and updated as well. What do you think? I'd like to hear about the pros/cons of this approach. As far as I can see, corporate users are the ones most interested in having their profiles data accessible from anywhere, and most corporations surely have an ftp server already in place. Not to mention ftp servers are standard, available everywhere, easy to manage, etc. Regards Fernando PS: An easier approach, an "entry step" would be to do this same thing, but instead of over ftp, to label the profile manager dialog "Enter profile location manually", so the user could type "Z:\mail-profiles\fcassia\", where drive Z: is really a remote network drive mounted on the local workstation. (via nfs/netware/netbeui/samba/winnetworking). (This would please only the corporate users roaming inside a corporate lan, but it would leave dialup users out, hence that's why I prefer the previously described ftp approach).

> where > the user might enter the "remote location" of their user profile, as an ftp url. FTP??? As in "send everything cleartext and play nasty tricks on me"? I would imagine that by feeding you a bad profile it should be pretty easy to take over your Mozilla completely without leaving much trace (as soon as you quit Mozilla and the temporary copy of the profile is deleted, there is no evidence profile was messed up with). Also, a part of the problem (especially for bookmarks) is beeing able to cope with more that one browser running simultaneously - e.g. I go home, without quitting Mozilla in my office and at home I add a few ne bookmarks to the shared profile and when I come back to my office, I see the new bookmarks there as well. This is not as hard as it may sound - we just need to make sure local profile are sync'ed with the remote one regularly, not just on start/exit. This should also answer questions like "what if Mozilla crashes after I spent an hour rearranging my bookmarks the way I like it"

FTP might be okay for a first cut, but a) as Aleksey points out, cleartext protocols are bad, b) how/where is the password going to be stored securely?, and c) not simple to only send the parts of files that have changed. Complaint c) might not be a first-cut issue, but definitely needs to be addressed at some point.

I don't think using HTTP is what's holding up this bug. How would using FTP would accelerate the process? Putting my sysadmin hat on, I'd much rather have a gaggle of users authenticate against an HTTP server, because there are a thousand and one authentication handlers available for apache. FTP servers are much more limited, even with PAM. Also, Mozilla is largely centered around HTTP already (API's,etc.). Wow, 110 votes.

I have a work in progress solution at http://bookie.mozdev.org. There's a java server and a client which are in a working state, modulo some features (notably moving and copying branches is absent right now). It uses Mozilla's RDF bookmark schema as the internal model, wrapped in XML-RPC commands.

A Java solution is okay and all but not a solution due to its licensing. (Not yours; Sun's.)

a few random thoughts, incorporating what i've read above, and elsewhere: it doesn't sound like anybody has the time to add roaming functionality to mozilla anytime soon. i don't. so let's just live with it. a better interim approach might be to just do the roaming file sync before and after mozilla runs, via a Perl script (as suggested by Philipp Kolmann). mainly we just need a remote place to store files, and such a Perl script. the Perl script could use any number of protocols or places for file/information storage. it could theoretically use LDAP, webdav, or ACAP, but i haven't seen any publicly available servers out there lately. (remember xdrive.com, idrive.com, driveway.com? they're no longer free, if they even still exist.) but if you're lucky, your ISP will probably give you an ftp, web, or IMAP account. storing the files on ftp is trivial. for web storage, you'll need roaming or webdav server extensions, which i don't think are common, although there's RIPglobal.com. if you don't have that, you'd have to write a cgi or php server that allows you to store files in your web account. also, you could store the files via IMAP (put them in a hidden folder so you don't accidentally delete them). ok, so once we have a place to store the files, we just need a Perl script to do the file sync. the script should allow us to sync arbitrary local files to arbitrary remote files, using some subset of protocols. (note: for LAN users we could even add "rsync", "rdist", or "mirror" support. but for common ISP users, we need a sync method that does its work through the common methods available from a typical ISP, or publicly available on the www. and to my knowledge, that leaves ftp, http, and imap. you could even use smtp and pop3, but that would truly be an ugly hack. also, you could conceivably store your files via a P2P protocol, but to insure persistence you'd probably have to name all your files "britney spears"....) so, anyway, when/if i have time, i'll try to write such a Perl script, probably using my ripglobal.com or my imap account as the remote storage place. also, note that since the script is external to mozilla, it could also sync your IE favorites (if you had any, but you don't, so nevermind.) the main weakness to this roaming method is, of course, that since synchronization is done at the file level, it's hard to truly merge the files properly without some extra information, which we don't have. so, what will probably happen is that, like netscape 4.x, either the local or the remote file will "win", and no real "merging" will take place. there are better solutions, but they would require changing mozilla. so the mozilla developers can stop reading now. to allow intelligent merging, we'd need to store the important files (bookmarks, address book, etc.) in sort of a database format, with transactions (ADD/DELETE with serial number), so that we know which are the new entries we want to keep, and which are the old ones that we already deleted. also, people have already mentioned integrating LDAP, ACAP, etc. into mozilla. but let me add that, since i don't think writable LDAP and ACAP servers are readily available to the common user, it might be easier to go the "duct tape" route and use something like IMAP, sort of like the way Outlook/Exchange stores its online contacts in a folder that's sort of accessible via IMAP. yeah, it would be a hack, but you could also store your bookmarks and anything else you want in IMAP. you could store each whole file in a big IMAP message, or you could split up the bookmarks and contacts into separate messages for better searching. but even with this LDAP/ACAP/IMAP integration, it would still be a good idea to store a local copy of the files, in case the server goes down. ok, that's about it for my brain dump.

> it doesn't sound like anybody has the time to add roaming functionality to > mozilla anytime soon. I plan to work on it after Mozilla 1.0, see bug 126029 (but please don't comment there).

Ben must be getting sleepy... The best places to find out about status of the funded version of this bug are bug 124026 and bug 124029. - Adam

Some features I would like: And this one might get you some corporate donations: a "push" configuration that reads the user's network account name and *automatically* sets up this config info (company home page / employee portal, IMAP server settings (IMAP login == network login), chatzillah nickname... the goal being: knowing no more than his login/password, user should be able to log in on a computer on the network for the first time and have a fully-functional mozilla installation with all the defaults set. And, when the user moves to another machine, this setup follows him, *without* using OS-specific profile features. Ability to decide what gets stored on the server and what doesn't. In the context of the above paragraph, that would allow an administrator to decide ahead of time what profile info will be centralized and what won't.

I think the previous comment shows how grand visions are holding back what could be here and now. Yes, the previous comment sounds like the holy grail of mobile computing, but will surelly be an implementation hell. What EXACTLY is "the user's network account name"? What network? TCP/IP? TCP/IP have no "account names". Would that be the Netware Requester that I have on my corporate lan? or netbios/netbeui? The "system name" on windows based PCs?. WTF are you talking about?? Why complicate things for no reason? Perhaps people need to go back to the origins of this bug#. If you read the initial post, in 1999 (yes 3 years ago), it said: >Is "roaming access" (as in Netscape Communicator 4.x) planned to be included >in Mozilla? > Roaming access = user profile (bookmarks/cookies/history/etc) is stored on > a central server. Client synchronizes local profile with the profile on the > server to be able to have same profile regardsless where the user is > localized. So why does everyone insist on ignoring this original need and instead propose revolutionary (and complicate) solve-everything-and-cook-dinner-too solutions? Just my $0.02

Sorry for sounding silly, but... Is "roaming access" (as in Netscape Communicator 4.x) planned to be included in Mozilla?

No. The problem is that the mozilla development team suffers from the delusion of grandeur, usual among the Open Source/Free Software developers. This is not a bad thing actually, since it leads to much good code (including the fact that, IIUC, mozilla is the most standard-compiant browser). Unfortunately, it has to be moderated by a realist leader (like RMS in Emacs and Miguel in Gnome) so that aiming for perfection does not get in the way of getting the job done. More specifically, TRT here is _really_ complex, so noone so far was able to define it (let alone code it). And "the poor man's solution" (which would satisfy many users), namely 1. reload the files changed since they were last read 2. add a "save current setup" menu item. is not glorious enough for anyone to implement. PS. just in case: the two items above allow for an external FTP solution: before leaving for home, you hit "save current setup" and mirror ~/.mozilla to the repository. when you get home, you mirror the repository to ~/.mozilla and mozilla reloads the changed files - no restart. PPS. the "next step" solution would be to aloow customization of the ~/.mozilla directory and specifying a URL there.......

I take it then that simply porting the existing Netscape functionality is non-trivial? I'm trying to get more people here using mozilla, but the standard response I get is: does it support roaming yet? None of these users want anything too complicated, they just want what they've already got with ns4. I imagine this is a show-stopper for many sites, as it is here. Perhaps there should be 2 mozilla bugs: o Port the existing Netscape 4.x roaming functionality, with no major new features. o Implement a fancy new roaming functionality.

There already ARE two such bugs! See comment #6 (or go directly to bug #17917).

ARG!!, please read what has been posted before. Comments 116 and 119 have been discussed at length before, see e.g. comment 94 and those around it. If you read the bug and the references carefully, you'd see that I am working on 4.x-like roaming at the moment, thanks to nice people willing to *pay* for it.

My comment 119 was not talking about code re-use from ns4. I was referring to porting solely ns4 *functionality*, as opposed to adding lots of fancy new functionality that people can't seem to agree on.

Ben Bucksch is already working on NS4 compatible roaming and functionality. Please see bug 124029 for more details.

Remove myself from the QA of open bugs and change to default QA contact, since I have no way to verify these easily. Still no working Mozilla on my primary platform and it doesn't look like it will happen anytime soon. :(

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

*** This bug has been marked as a duplicate of 152809 ***

Was that DUPE intentional?

(That dupe created a "circular dupe loop". -- That sounds cool) I thought bugzilla checked for those...

bug 154617 filed on the duplicate loop problem. Bugzilla used to check for that, so something must have broken.

We need to support multiple protocols so that many people can use this. ACAP is cool, HTTPS is secure, and just about everybody has FTP. There are two levels of functionality here: Poor man's version: 1. On startup, copy the prefs from (HTTP,FTP,insert protocol here) to hard drive 2. On shutdown (or when the user asks) copy the prefs from hard drive to (HTTP,FTP,insert protocol here) This would satisfy most people's needs. Heavy-duty version: 1. On startup, copy the prefs from (HTTP,FTP,insert protocol here) to hard drive 2. When the user changes a pref, upload it 3. When the user changes a pref remotely, download it Since this is all profile info and not just prefs, we may not be able to get deltas for everything to upload all the time so we'll need a hybrid. But it's better than nothing. And support towards the heavy-duty can be built up over time, too, if we start with the poor man's version.

related reading: http://mozilla.freezope.org/PRM/PRM02 http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3D4E2B01.3050607%40netscape.com&rnum=10&prev=/&frame=on

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

I understand why the old Netscape 4.x code is basically useless now. Here's what I don't understand. Netscape already supported roaming when Mozilla was in the process of rewriting everything under the sun. So why wasn't roaming considered an "NS4 parity" essential, as were major components like Mail/News that had to be rewritten from scratch? If some thought and effort went into making a general profile management backend back then, we wouldn't have this dilemma now. The local file-based profile information could have just been one more pluggable backend for the profile manager, along with HTTP (mod_roaming), FTP, ACAP, LDAP and anything else that makes sense. It could be dynamically synchronized on an item-by-item basis, and we wouldn't have to be worrying about how to hook into the myriad pieces of code that are now a concern... Did it occur to nobody that hardcoding all the new profile code to assume file management would cause trouble down the road? Wasn't the existing Netscape 4 support a compelling reason to avoid this problem upfront? Given the amount of code that was rewritten anyway, it would have been much easier to incorporate the needed changes during the rewrite to do it the Right Way... I'm not slamming anybody here. These things happen, and things fall through the cracks. There were so many high-profile Netscape 4 features that this one was probably too small to attract attention until it was too late. I didn't think to point this out early on, either. It's just frustrating that we're in this situation when a little foresight at the right time could have avoided this problem entirely. Oh well, I guess there's only so much foresight to go around. Of course, this bug is now more than 3 years old. When it was filed, only a year had passed since the decision to scrap the classic codebase -- now we have 4 years of code to contend with instead of 1 year of code. If it was daunting in 1999 to implement this, I shudder to think of the difficulty NOW... :-(

This is a very serious limitation because it makes it so difficult to move bookmarks between computers and discourages backup of bookmarks. I did export bookmarks about a month ago to edit them on Netscape 4.79, which is a better for editing large sets of bookmarks. That's the last backup I did. Installing Mozilla 1.2.1 over 1.2 on Windows 2000 just wiped out all my bookmarks. This would not be a problem with bookmarks in a file as in the old Netscape. Bookmark management is the reason I stayed with the old Netscape until Mozilla came out. I have used Mozilla ever since, but this experience completely undermines any confidence in continuing to use it. kahin@wyoming.com

Here are a couple of thoughts on roaming: NS4 supported roaming, but it had a couple of extremely obnoxious misfeatures: a) For one thing, if you set a preference to a nonstandard setting, allowed it to be uploaded, and then wanted to change it back you were utterly screwed -- the "back to standard" setting wouldn't propagate and the nonstandard setting would overwrite it at all times. b) It only synced on open and shutdown. It meant you could lose data if you had left a Netscape running just about anywhere while using another. c) It didn't support .newsrc at all. A lot of thoughts in this thread seem to revolve around "make it compatible with <foo>." It seems it would be more useful to get a roaming infrastructure that does what really needs to be done, and if it is not compatible with the old stuff that is unfortunate but it's much better than the current situation, *or* with retaining misfeatures of the old one. What this really is a form of a version-control system: when two different versions of a file is presented, they need to be merged intelligently.

Peter -- see bug #17917, "Add 'smart' roaming bookmarks (etc.) with sync capabilities".

I'll ask this again: Can we please keep advocacy (i.e. whining about why this bug isn't fixed, about how important it is, about how it should have been done by now, about how easy it would be, etc) OUT of the bug. We get the idea already! We just need someone to step up and actually do the work.

> We just need someone to step up and actually do the work. heh. Done. Bug 124029. (But please don't comment there.) Say thanks to Matt Perry (private) and Dave Caplinger (of Meridianmap) and others who agreed to pay $$$ to make it possible.

>> We just need someone to step up and actually do the work. > heh. Done. Bug 124029. (But please don't comment there.) Then one of these bugs should be a duplicate or dependent on the other. No?

> Then one of these bugs should be a duplicate or dependent on the other. No? No. This bug is useless to track work, because it has been spammed way too much. Marking this a dup of the other bug will make the spam go there, making that bug useless as well. There are a few good ideas (which I did not implement) thrown around here, occasionally, so I don't know yet what should happen with this bug. Somebody could write a webpage, summarizing the ideas.

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

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

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

I don't know if this has been suggested in the past, but how about using a protable USB disk to store the profile? this would have several benefits over an online repository, including better performance, better price/MB ratio and most probably - simpler implementation. Prog.

Isn't that just a glorified SneakerNet? A much *worse* price MB/ratio -- and worse performance too, once you factor in "fiddling with physical devices rather than having the computer do the work for you". And it can't be in more than one place at once.

An interesting idea, I guess. If you are using a real OS you can softlink $HOME/.mozilla to your USB mount already. The other thing is that it does not scale well. That does not matter if your target audience is one or two people with USB drives/disk-on-key, but where I think this feature will really make a difference is where an administrator can set up the feature for many people at once. College campuses where people log in to different machines all the time, etc, could really benefit. It would be neat to have an LDAP schema containing the heart of the profile, without the cache, etc.

This might be veering a bit offtopic, but I suppose that's ok seeing as not much seems to be going on with this bug anyway... What about a system where a person can carry around ID and password information their USB keychains that specify where the profile is stored and how to access it? That way the profile can be on the keychain or on the network, and by reading the drive Mozilla will have all credentials needed to access it as well. Some sort of checking for a specially named file in the root of any possibly USB drive would be called for, I suppose, though I don't know how this would be done nicely under non-windows machines... Just brainstorming

Please, this is entirely irrelevant to Mozilla roaming. USB SneakerNet is fine for what it does, but it is utterly unable to do what real networks can. This is why the Internet itself doesn't mainly function by people passing floppy disks from point to point. Any further brainstorming on that topic should go elsewhere.

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

you can tell mozilla where it finds the mails for each account. that's what is very useful for roaming profiles. but why can't we do it with all other personal files, like cookies.txt, etc.? I really appriciate everyone implementing this! Michael

The central repository has to be on the web? Maybe it would be nicer to choose between various information sources like: - create a new profile on disk - create a new roamming profile on disk - load a roamming profile from a web server - load a roamming profile from disk - Use this profile next time you open mozilla? y/n

For the sake of new people coming to this bug as well as those implementing potential solutions to this bug, what subsystems /should/ be included in 'roaming', and are they modular already (that is, could we change their "look here for data" settings?) I'll suggest: - Bookmarks - E-mail server settings - Contact lists - Proxy, general browser settings

Apologies for spam, but this bug has been fixed: see bug #124029

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

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

This was fixed in bug 124029, which was one/a implementation bug of this feature request. Please do not add comments to that bug. Cleaning out dependencies. Interesing related bugs in there: Bug 147344 - Breaking up the profile for roaming, sharing and performance Bug 18043 - Allow bookmarks to reside remotely on an arbitrary user-defined host Bug 17917 - Add "smart" roaming bookmarks (etc.) with sync capabilities For the record, this bug currently has 238 votes, bug 124029 has 112. I am collecting votes :-).

Marking dup of impl bug.

Marking dup of impl bug. *** This bug has been marked as a duplicate of 124029 *** *** This bug has been marked as a duplicate of 124029 ***