Closed Bug 17048 Opened 23 years ago Closed 19 years ago

Roaming access - keep bookmarks/cookies/history/etc in a central repository


(SeaMonkey :: UI Design, enhancement, P3)



(Not tracked)



(Reporter: saska, Assigned: BenB)



(Keywords: helpwanted, meta)

Is "roaming access" (as in Netscape Communicator 4.x) planned to be included in

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.
Blocks: 11460
Closed: 23 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED, this is a great question to ask on the Newsgroups. (For more
information, see 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???

Resolution: WONTFIX → ---
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.
Assignee: don → saska
Summary: roaming access - download bookmarks/cookies/history/etc from a central repository → roaming access - keep bookmarks/cookies/history/etc in a central repository
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
see also bug #17817, which is a feature suggestion for a smarter version of
sorry, typo. that should be bug #17917
Blocks: 17917
Summary: roaming access - keep bookmarks/cookies/history/etc in a central repository → [RFE] roaming access - keep bookmarks/cookies/history/etc in a central repository
*** 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:
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.
Keywords: helpwanted
QA Contact: leger → saska
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 "" 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.)
Assignee: saska → markush
QA Contact: saska → markush
Summary: [RFE] roaming access - keep bookmarks/cookies/history/etc in a central repository → [RFE] roaming access / ACAP - keep bookmarks/cookies/history/etc in a central repository
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

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..
Depends on: 31763, 31764, 31766
Keywords: meta
Target Milestone: M17
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

See <> and
<> for module owners, e.g.
for Necko (or netlib or network library or netwerk) and for
Preferences UI.

Assign this bug to, 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 for now. Not giving up though.
Assignee: markush → nobody
QA Contact: markush → nobody
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
Summary: [RFE] roaming access / ACAP - keep bookmarks/cookies/history/etc in a central repository → [RFE] Roaming access - keep bookmarks/cookies/history/etc in a central repository
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
QA Contact: nobody → David
*** 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
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. :)
Keywords: 4xp, mozilla1.0
Target Milestone: M17 → mozilla1.0
Target Milestone: mozilla1.0 → ---
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 
(, 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 

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

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...
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
Keywords: nsenterprise
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

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

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.
Depends on: 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.
Depends on: 18043
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
No longer depends on: 31766
Blocks: 31766
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.
Assignee: nobody → jpm
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

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

Keywords: nsenterprise-
*** 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. ;-)
Component: Browser-General → XP Apps
Scott, please find a new home for these bugs.  Thx!
Assignee: jpm → putterman
what about DAV for roaming ? (

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

Keywords: nsenterprise
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  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 <> 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. 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:

If you want server-side example code, try this:

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:
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
Assignee: putterman → nobody
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:

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?

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

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

Philipp Kolmann

PS: Don't assign this but to me, I just want to do some testing, if it is
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.

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, 


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

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

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. :(
QA Contact: mozilla → paw
Depends on: 147344
*** Bug 152809 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 152809 ***
Closed: 23 years ago20 years ago
Resolution: --- → DUPLICATE
Was that DUPE intentional?
Resolution: DUPLICATE → ---
(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.
No longer blocks: 31766
Blocks: majorbugs
Summary: [RFE] Roaming access - keep bookmarks/cookies/history/etc in a central repository → Roaming access - keep bookmarks/cookies/history/etc in a central repository
*** 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

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.

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

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!
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 :-).
Assignee: nobody → ben.bucksch
No longer blocks: 11460, 17917, advocacybugs, majorbugs
No longer depends on: 18043, 31763, 31764, 147344
Marking dup of impl bug.
Closed: 20 years ago19 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha
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 ***
Product: Core → Mozilla Application Suite
Blocks: majorbugs
No longer blocks: majorbugs
You need to log in before you can comment on or make changes to this bug.