Closed
Bug 17048
Opened 25 years ago
Closed 20 years ago
Roaming access - keep bookmarks/cookies/history/etc in a central repository
Categories
(SeaMonkey :: UI Design, enhancement, P3)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 124029
mozilla1.8alpha1
People
(Reporter: saska, Assigned: BenB)
References
Details
(Keywords: helpwanted, meta)
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.
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 1•25 years ago
|
||
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...
Assignee | ||
Updated•25 years ago
|
Status: VERIFIED → REOPENED
Assignee | ||
Comment 2•25 years ago
|
||
elig, why is this won't fix???
Reopening.
Assignee | ||
Updated•25 years ago
|
Resolution: WONTFIX → ---
Assignee | ||
Comment 3•25 years ago
|
||
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.
Reporter | ||
Updated•25 years ago
|
Assignee: don → saska
Status: REOPENED → NEW
Summary: roaming access - download bookmarks/cookies/history/etc from a central repository → roaming access - keep bookmarks/cookies/history/etc in a central repository
Reporter | ||
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
see also bug #17817, which is a feature suggestion for a smarter version of
this.
Comment 6•25 years ago
|
||
sorry, typo. that should be bug #17917
Reporter | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Summary: roaming access - keep bookmarks/cookies/history/etc in a central repository → [RFE] roaming access - keep bookmarks/cookies/history/etc in a central repository
Comment 8•25 years ago
|
||
What about including support for FNS/NIS+ (Solaris/Linux) (this was rfe/bug
20684)... ?
Comment 9•25 years ago
|
||
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...
Comment 10•25 years ago
|
||
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
Assignee | ||
Comment 11•25 years ago
|
||
yes, there was a (positive) discussion about ACAP recently on n.p.m.mail-news.
Comment 12•25 years ago
|
||
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.
Comment 13•25 years ago
|
||
Putting on helpwanted keyword radar. At this time a net community engineer
would need to implement this.
Keywords: helpwanted
QA Contact: leger → saska
Assignee | ||
Comment 14•25 years ago
|
||
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.
Comment 15•25 years ago
|
||
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.)
Assignee: saska → markush
Status: ASSIGNED → NEW
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
Assignee | ||
Comment 16•25 years ago
|
||
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).
Comment 17•25 years ago
|
||
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.
Assignee | ||
Comment 18•25 years ago
|
||
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.
Comment 19•25 years ago
|
||
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!
Assignee | ||
Comment 20•25 years ago
|
||
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.
Assignee | ||
Comment 21•25 years ago
|
||
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.
Comment 22•25 years ago
|
||
LAN/WAN comments from above branched off into bug 31732.
Comment 23•25 years ago
|
||
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..
Assignee | ||
Updated•25 years ago
|
Assignee | ||
Comment 24•25 years ago
|
||
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.
Comment 25•25 years ago
|
||
Reassigning to nobody@mozilla.org for now. Not giving up though.
Assignee: markush → nobody
QA Contact: markush → nobody
Comment 26•25 years ago
|
||
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.
Comment 27•25 years ago
|
||
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.
Comment 28•25 years ago
|
||
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.
Comment 29•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
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
Comment 30•25 years ago
|
||
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.
Comment 31•25 years ago
|
||
*** Bug 34230 has been marked as a duplicate of this bug. ***
Comment 32•25 years ago
|
||
*** Bug 34230 has been marked as a duplicate of this bug. ***
Comment 33•24 years ago
|
||
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.
Comment 34•24 years ago
|
||
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.
Comment 35•24 years ago
|
||
Taking QA contact since it is currently nobody@mozilla.org.
QA Contact: nobody → David
Comment 36•24 years ago
|
||
*** Bug 11460 has been marked as a duplicate of this bug. ***
Comment 37•24 years ago
|
||
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?
Comment 38•24 years ago
|
||
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
Comment 39•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla1.0 → ---
Assignee | ||
Comment 40•24 years ago
|
||
David, I think, nobody prefers to have all his bugs sat to Milestone "---". :-)
Comment 41•24 years ago
|
||
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.
Comment 42•24 years ago
|
||
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.
Comment 43•24 years ago
|
||
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?
Comment 44•24 years ago
|
||
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...
Assignee | ||
Comment 45•24 years ago
|
||
Comment 46•24 years ago
|
||
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.
Comment 47•24 years ago
|
||
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 ???
Comment 48•24 years ago
|
||
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.
Comment 49•24 years ago
|
||
I think XBEL is the shapeliest solution
http://pyxml.sourceforge.net/topics/xbel/
Keywords: nsenterprise
Comment 50•23 years ago
|
||
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
Comment 51•23 years ago
|
||
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 :)
Comment 52•23 years ago
|
||
For some related but not quite so general work, see bug 18043.
Depends on: 18043
Comment 53•23 years ago
|
||
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
Comment 54•23 years ago
|
||
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.
Comment 55•23 years ago
|
||
Added to CC
Comment 56•23 years ago
|
||
I agree with Alec completely, that is the optimal way to go about it.
Comment 57•23 years ago
|
||
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.
Comment 59•23 years ago
|
||
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.
Comment 60•23 years ago
|
||
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".
Comment 61•23 years ago
|
||
individual protocols should be listed in new bugs. This bug is just for the
architectural design of roaming, with pluggable protocols
Comment 62•23 years ago
|
||
*** Bug 100366 has been marked as a duplicate of this bug. ***
Comment 63•23 years ago
|
||
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.
Comment 64•23 years ago
|
||
Good point; that should probably be RFE'd as a separate bug.
Comment 65•23 years ago
|
||
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
Keywords: nsenterprise-
Comment 66•23 years ago
|
||
*** Bug 110087 has been marked as a duplicate of this bug. ***
Comment 67•23 years ago
|
||
For those who are interested: Ben's suggestion is already in bugzilla: #78072
Comment 68•23 years ago
|
||
sorry, let me make that a link: bug #78072
Comment 69•23 years ago
|
||
and when I say "Ben", I mean "Bob", in comment 63. Sorry about that.
Okay, enough spam from me.
Comment 70•23 years ago
|
||
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. ;-)
Updated•23 years ago
|
Component: Browser-General → XP Apps
Comment 71•23 years ago
|
||
Scott, please find a new home for these bugs. Thx!
Assignee: jpm → putterman
Comment 72•23 years ago
|
||
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.
Comment 73•23 years ago
|
||
Shouldn't this bug be marked as dependent on bug 66259?
Comment 74•23 years ago
|
||
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.
Updated•23 years ago
|
Keywords: nsenterprise
Comment 76•23 years ago
|
||
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.
Comment 77•23 years ago
|
||
there's no way we're ever going to ressurect the 4.x roaming code. mozilla has
diverged too much.. sorry.
Comment 78•23 years ago
|
||
------- 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.
Assignee | ||
Comment 79•23 years ago
|
||
> 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.
Comment 80•23 years ago
|
||
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.
Comment 81•23 years ago
|
||
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.
Comment 82•23 years ago
|
||
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.
Comment 83•23 years ago
|
||
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 :)
Comment 84•23 years ago
|
||
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.
Comment 85•23 years ago
|
||
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.
Assignee | ||
Comment 86•23 years ago
|
||
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.
Comment 88•23 years ago
|
||
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.
Comment 89•23 years ago
|
||
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.
Comment 90•23 years ago
|
||
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.
Comment 91•23 years ago
|
||
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.
Comment 92•23 years ago
|
||
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
Comment 93•23 years ago
|
||
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"
Comment 94•23 years ago
|
||
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.
Comment 95•23 years ago
|
||
I'm not the right owner for this. Reassigning to nobody@mozilla.org.
Assignee: putterman → nobody
Comment 96•23 years ago
|
||
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?
Comment 97•23 years ago
|
||
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.
Comment 98•23 years ago
|
||
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
Comment 99•23 years ago
|
||
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
Comment 100•23 years ago
|
||
Assignee | ||
Comment 101•23 years ago
|
||
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.
Comment 102•23 years ago
|
||
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.
Assignee | ||
Comment 103•23 years ago
|
||
Updated•23 years ago
|
Blocks: advocacybugs
Comment 104•23 years ago
|
||
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).
Comment 105•23 years ago
|
||
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.
Comment 106•23 years ago
|
||
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).
Comment 107•23 years ago
|
||
> 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"
Comment 108•23 years ago
|
||
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.
Comment 110•23 years ago
|
||
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.
Comment 111•23 years ago
|
||
A Java solution is okay and all but not a solution due to its licensing. (Not
yours; Sun's.)
Comment 112•23 years ago
|
||
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.
Assignee | ||
Comment 113•23 years ago
|
||
> 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).
Comment 114•23 years ago
|
||
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
Comment 115•23 years ago
|
||
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.
Comment 116•22 years ago
|
||
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
Comment 117•22 years ago
|
||
Sorry for sounding silly, but...
Is "roaming access" (as in Netscape Communicator 4.x) planned to be included
in Mozilla?
Comment 118•22 years ago
|
||
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.......
Comment 119•22 years ago
|
||
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.
Comment 120•22 years ago
|
||
There already ARE two such bugs! See comment #6 (or go directly to bug #17917).
Assignee | ||
Comment 121•22 years ago
|
||
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.
Comment 122•22 years ago
|
||
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.
Comment 123•22 years ago
|
||
Ben Bucksch is already working on NS4 compatible roaming and functionality.
Please see bug 124029 for more details.
Comment 124•22 years ago
|
||
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
Comment 125•22 years ago
|
||
*** Bug 152809 has been marked as a duplicate of this bug. ***
Comment 126•22 years ago
|
||
*** This bug has been marked as a duplicate of 152809 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 22 years ago
Resolution: --- → DUPLICATE
Comment 127•22 years ago
|
||
Was that DUPE intentional?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 128•22 years ago
|
||
(That dupe created a "circular dupe loop". -- That sounds cool)
I thought bugzilla checked for those...
Comment 129•22 years ago
|
||
bug 154617 filed on the duplicate loop problem. Bugzilla used to check for
that, so something must have broken.
Comment 130•22 years ago
|
||
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.
Summary: [RFE] Roaming access - keep bookmarks/cookies/history/etc in a central repository → Roaming access - keep bookmarks/cookies/history/etc in a central repository
Comment 131•22 years ago
|
||
Comment 132•22 years ago
|
||
*** Bug 180669 has been marked as a duplicate of this bug. ***
Comment 133•22 years ago
|
||
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... :-(
Comment 134•22 years ago
|
||
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
Comment 135•22 years ago
|
||
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.
Comment 136•22 years ago
|
||
Peter -- see bug #17917, "Add 'smart' roaming bookmarks (etc.) with sync
capabilities".
Comment 137•22 years ago
|
||
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.
Assignee | ||
Comment 138•22 years ago
|
||
> 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.
Comment 139•22 years ago
|
||
>> 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?
Assignee | ||
Comment 140•22 years ago
|
||
> 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.
Comment 141•22 years ago
|
||
*** Bug 187880 has been marked as a duplicate of this bug. ***
Comment 142•22 years ago
|
||
*** Bug 188542 has been marked as a duplicate of this bug. ***
Comment 143•22 years ago
|
||
*** Bug 189587 has been marked as a duplicate of this bug. ***
Comment 144•21 years ago
|
||
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.
Comment 145•21 years ago
|
||
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.
Comment 146•21 years ago
|
||
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.
Comment 147•21 years ago
|
||
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
Comment 148•21 years ago
|
||
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.
Comment 149•21 years ago
|
||
*** Bug 20683 has been marked as a duplicate of this bug. ***
Comment 150•21 years ago
|
||
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
Comment 151•21 years ago
|
||
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
Comment 152•21 years ago
|
||
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
Comment 153•20 years ago
|
||
Apologies for spam, but this bug has been fixed: see bug #124029
Assignee | ||
Comment 154•20 years ago
|
||
*** Bug 31763 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 155•20 years ago
|
||
*** Bug 31764 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 156•20 years ago
|
||
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 | ||
Comment 157•20 years ago
|
||
Marking dup of impl bug.
Status: NEW → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha
Assignee | ||
Comment 158•20 years ago
|
||
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 ***
Resolution: FIXED → DUPLICATE
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•