Closed Bug 178806 Opened 22 years ago Closed 16 years ago

provide IPC mechanism for profile sharing, etc.

Categories

(Core :: IPC, enhancement)

Product:
Core
Component:
IPC
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: darin.moz, Unassigned)

References

Details

(Keywords: topembed+, Whiteboard: [adt2] [ETA: June 12, 2003])

Attachments

(5 files, 1 obsolete file)

response to timeless (comment #4)
10.96 KB, text/plain
Details
response to timeless (comment #6)
1.98 KB, text/plain
Details
patch for allmakefiles.sh and Makefile.in
1.21 KB, patch
Details | Diff | Splinter Review
review comments from brendan
4.33 KB, text/html
Details
[beos] updated patch to fix Deskbar issue
8.77 KB, application/zip
Details
provide IPC mechanism for profile sharing, etc. the requirement in a nutshell is to provide an out-of-process daemon and messaging system. client applications can connect to the daemon and send messages to particular "daemon modules" identified by UUID. daemon modules can send messages to any client connected to the daemon. clients may have several message handlers, each identified by UUID. hence, messages from the client contain the UUID of the target module, and messages from the module contain the UUID of the target message handler for a given client. the daemon must support plug-in modules. this requirement is meant to allow PSM the option to implement a module that would host a shared cert database, for example. the daemon can also provide a mechanism for client discovery. this may be accomplished by allowing clients to register themselves under common names. the daemon can then be used "like a DNS server" to resolve a name like "browser" into the client ID (the "address") of the client registered under that name. the daemon can then also provide a simple mechanism for forwarding messages from one client to another. for example, a "browser" app might request something from the "addressbook" app and vice versa. this forwarding mechanism also makes possible a form of d-xpcom (which dougt has prototyped). lastly, this IPC mechanism should not get in the way of mozilla doing its normal thing. if the IPC mechanism should fail for whatever reason, it must not bring down the rest of mozilla! ;-) so, i've been developing this "patch" on the trunk under modules/ipc (not pulled by default), but the plan is ultimately to move it out of modules/ since that is a deprecated part of the tree. mozilla/ipc may become its new home. please check out the code in modules/ipc, and let me know what you think.
oh, i forgot to mention: i've tested the code under rh7.3, rh8.0, win2k, and osx10.1.5 (mach-o). the windows impl uses WM_COPYDATA messages, and the others use TCP/UNIX sockets (leveraging necko heavily). the windows impl introduces a new thread for the hidden window's message pump (in order to not block the main thread when sending/receiving messages).
Severity: normal → major
Status: NEW → ASSIGNED
Keywords: mozilla1.3, topembed
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha
Blocks: 135137
Marking as topembed+ per EDT triage, as this is needed for GRE, and desired by a major embedding customer.
Keywords: topembed → topembed+
Whiteboard: [adt2] [ETA Needed]
Target Milestone: mozilla1.3alpha → mozilla1.3beta
Blocks: 185706
looks fine. r=dougt.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/build/Makefile.in&rev=1.2&mark=49,50,53#45 i don't think a module should ever need to require itself. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/build/ipcCID.h&rev=1.1&mark=44#41 here's a quick survey: [timeless@viper mozilla-1.3a]$ ./run-mozilla.sh ./xpcshell js> const C=Components.classes,I=Components.interfaces; js> b=0; for (a in C) if (/\/service/.test(a)) ++b; 6 js> b=0; for (a in C) if (/-service/.test(a)) ++b; 39 js> b=0; for (a in C) if (/[^-\/]service/.test(a)) ++b; 30 - is the most common, / is very rare. (no delim is more common.) please use -. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/build/ipcModule.cpp&rev=1.5&mark=52,85,101,102,104-105 please either remove the code or make it so that it could be consistently flipped on, right now changing from #if 0 to #if 1 and then removing the /* and */ would result in compile errors. At the very least remove the /**/ notation. as directories go, /common/ doesn't match *any* convention present in the mozilla tree. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcConfig.h&rev=1.8&mark=72#68 is this absolutely safe? what happens if user timely creates /tmp/.mozilla-ipc and then user timeless tries to use a mozilla-ipc app? can timely prevent timeless's app from working or otherwise interfere? Is there any serious documentation which explains why these classes exist as they do? I'd like to know why we need the string classes you're creating, we already have a bunch of datastructures in xpcom including a deque, some arrays with deletion/insertion capabilities. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcStringList.h&rev=1.3&mark=64#62 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcMessage.h&rev=1.4&mark=177#176 that's a great comment, could someone please flesh it out? http://lxr.mozilla.org/mozilla/source/modules/ipc/common/ipcLog.cpp there's no os/2 impl (mkaply), and there's no macos impl, and who else did you miss? please give those people a heads up before you break them. sys/types.h, are you sure there isn't a configure test that looks for this? (cls) > do any of these files ever live in interesting places: > sys/types.h, sys/stat.h, unistd.h, fnctl.h, signal.h? <cls> sometimes they don't exist at all <cls> fcntl.h & signal.h in particular (and sometimes you want sys/signal.h) http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcMessage.h&rev=1.4&mark=114-115#112 I don't think you mean what you wrote. I think 'only' should be dropped. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcMessagePrimitives.cpp&rev=1.2&mark=45#40 should this be PRInt32? unsigned int + 2 > max unsigned int http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcIDList.cpp&rev=1.1&mark=48,54,61 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcList.h&rev=1.2&mark=61-62,82,162,169 <and many others> don't use NULL. use nsnull or 0. ipcMessage::Clone() and ipcMessage::ipcMessage(const ipcMessage&) 1. you don't declare the later illegal which means someone could mess up and use it. 2. Clone isn't virtual, so why not just change Clone() to be a copy constructor and do things that way? http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcList.h&rev=1.2&mark=66-68,77-79,91-93,102-104,111-113,124-126,136-138,148-150 <and many others> please use doxygen friendly /**\n * comments\n */ please use doxygen friendly @param and @return and ... 52 // XXX ipcMessageCast is probably not the best name for this class. hrm, this class looks like syntactic sugar. IPCM_MSG_TYPE_CLIENT_DEL_TARGET there's no documentation for this. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcm.h&rev=1.9&mark=270,254,272 there are typos/minor errors in the documentation http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/daemon/Makefile.in&rev=1.7&mark=56,58-59#55 this doesn't scale nicely for OS/2 and Mac ... http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/daemon/Makefile.in&rev=1.7&mark=78#75 why don't you link against the version in common? http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/daemon/ipcCommandModule.cpp&rev=1.18&mark=68,74,75#59 your calloc could be a malloc w/ a null assignment for str[count] on line 75 http://lxr.mozilla.org/mozilla/source/modules/ipc/daemon/ipcModule.h should struct ipcDaemonMethods be extern C? ah, it can't be. the only change required would be from nsID& to nsID*. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/daemon/ipcModuleReg.h&rev=1.6&mark=44-45#43 so, if i call IPC_InitModuleReg, IPC_ShutdownModuleReg, IPC_InitModuleReg, IPC_ShutdownModuleReg, then i can't call IPC_InitModuleReg again? :) If you want to allow that next call, then something like this would work: IPC_InitModuleReg can not be called more than once before calling IPC_ShutdownModuleReg. http://lxr.mozilla.org/mozilla/source/modules/ipc/daemon/ipcModuleUtil.h <and others> Don't use PR_ASSERT. you require XPCOM, so use NS_ASSERTION. 64 PRStatus 65 IPC_SendMsg(ipcClient *client, ipcMessage *msg) 75 delete msg; This transfer of ownership worries me, it is documented, but i don't think it's a good idea. is there some real benefit to capturing ownership on success? why not always leave it to the caller? 104 // we use fcntl for locking. assumption: filesystem should be local. you can't make these assumptions. and again /tmp seems evil. 123 // write our PID into the lock file (this just seems like a good idea... 124 // no real purpose otherwise). instead of reinventing locking, why don't you use the profile lock code? it should live in xpcom, if it doesn't then you can file a bug and get that fixed. http://lxr.mozilla.org/mozilla/source/modules/ipc/daemon/ipcdUnix.cpp 402 listenFD = PR_OpenTCPSocket(PR_AF_LOCAL); 403 if (!listenFD) { 404 LOG(("PR_OpenUDPSocket failed [%d]\n", PR_GetError())); right... fix the message :) i was pretty sure that we wanted files to have modelines to help editors out. the file i'm looking at doesn't ... There once was a generic ban on adding templates randomly. you've added this stringlist template which imo could have been handled by a simple base class. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/common/ipcList.h&rev=1.2&mark=47-51 is a contract which your template doesn't actually enforce but which could _easily_ have been enforced by a baseclass. Please have scc or someone take a _serious_ look at this module before you land it somewhere proper. more later. -- concerns, what prevents user timely from sending data to a mozilla-ipc process timeless is running? (w32, unix) as for directory names, mozilla/geckoipc seems reasonable, and something can be done like this for the contracts too. this ipc is designed for ipc w/in mozilla clients not ipc w/ the rest of the os, and i'd like to reserve @mozilla.org/ipc-* for that.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcService.cpp&rev=1.18&mark=202,366,378#179 the callee will complain about null. in almost all other instances you avoid calling it w/ null. in the second instance you could and probably should return outofmemory http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcService.cpp&rev=1.18&mark=297-299,323-325,#296 you crash if the query creation fails http://lxr.mozilla.org/mozilla/source/modules/ipc/src/ipcSocketProviderUnix.cpp&rev=1.4&mark=42#41 traditionally nspr yells and screams when people use nspr private methods... (wtc) http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransport.cpp&rev=1.13&mark=190-192#189 you could be nice to the processor and skip the math and compare mConnectionAttemptCount with 6 instead of ms w/ 1000 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransport.h&rev=1.9&mark=71,75#68 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransport.cpp&rev=1.13&mark=205#204 This looks like NS_IMPL_THREADSAFE_ISUPPORTS1 to me... http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransportUnix.cpp&rev=1.8&mark=145,146#135 the sent hello assignment is optimistic and will be incorrect if the new fails. theoretical nit, a box could run ipv6 w/o ipv4. or someone could be using browser+mail w/o any version of ip... minor perf warning, PR_GetEnv can be expensive on some platforms, and since its value shouldn't change you might want to consider caching it (static) http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransportWin.cpp&rev=1.9&mark=123,126 you crash if new fails http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/ipc/src/ipcTransportWin.cpp&rev=1.9&mark=263 you aren't supposed to do explicit comparisons w/ PRBools. use if (foo) or if (!foo) -- more later, i'm catching a bus to toledo and then i'm traveling until late tomorrow. i'll get the last dirs next week. (i skimmed your responses just now but am out of time)
nevermind my comment about using a randomly generated directory in /tmp... other processes need to be able to locate the directory, so it must have a well known location.
Darin: will there be steps I can use to verify this when it is implemented, or should I get an API tester for this bug?
it might be good to have an API tester look at this. there won't be any application to test (other than the TestIPC application).
QA Contact: benc → depstein
QA Contact: depstein → ashishbhatt
1.4 is the big embedding milestone. hoping to finalize the ipc module by 1.4 alpha.
Keywords: mozilla1.3
Target Milestone: mozilla1.3beta → mozilla1.4alpha
you'll need to set MOZ_IPC=1 as an environment variable before building.
latest bits now reside on the branch "IPC_BRANCH_20030304" and live under mozilla/ipc/ipcd/. this directory structure was approved by brendan. there's now an extensions directory that currently just contains a lock service. we will be adding the transaction manager component as an extension.
Target Milestone: mozilla1.4alpha → mozilla1.4beta
Severity: major → enhancement
it seems we need special implementation if it for BeOS or disabling all related things by default. Maybe it should be based on BMessages, not on sockets
should this be marked fixed now?
saari: no, because i still need to work in brendan's review comments and finally, i need to land the IPC service on the trunk. it currently just lives on a branch, and that is what the trunk is pulling. i'd like to keep this bug open to finish up the nitty gritty.
I need to figure out what to do on OpenVMS. We don't have local (UNIX domain) sockets. If I need to replace the use of local sockets with something else, what is the set of routines I need to implement?
colin: you would need to implement ipcTransport for VMS. please see ipcTransportUnix and ipcTransportWin for examples. in the meantime, we should probably disable profilesharing for VMS builds.
Disabling it in configure.in for VMS, along with the platforms without implementations, would probably be bug 204177.
Colin Blake wrote: > I need to figure out what to do on OpenVMS. We don't have local (UNIX domain) > sockets. If I need to replace the use of local sockets with something else, > what is the set of routines I need to implement? Maybe the best solution would be to use libICE (which should be preferred on X11 platforms in general over the home-grown code which is currently be used for Mozilla IPC) ...
Component: Networking → IPC
Is there any interest in an ICE solution for X11 platforms? Or should I just make the existing UNIX code use regular sockets for OpenVMS (daemon could write address and port into the lock file, clients can connect using the information they read from the lock file)?
colin: that sounds like a great plan. the only issue is that be sure to verify that the existing ownership checks on the lock file are kept in place. it is crucial that the lock file be owned by the user and be accessible only be the user. of course, i think you still would have a security hole if someone were doing port scanning. the problem being that any process owned by any user could technically connect to the TCP port. you could of course limit access to only those users with a local account, but that doesn't prevent the port scanning exploit. basically, this is the reason why i didn't just use TCP/IP under windows.
Sorry for jumping uninvited and without looking at the code, but if the windows implementation is using the WM_COPYDATA, then there might be a problem when using the IPC with the windows XP fast user switching feature. When fast user switcing is used FindWindow can not find the mozilla window only which was opened for another user. This will imply that a deamon will be run for each user, which is not what I think of as a deamon. IMHO a better implementation for XP will be to use named pipes.
re: comment 24 To prevent port scanning the daemon could write a random number along with the address and port into the lock file. Then when a client connects it has to first send the random number, and if the daemon doesn't receive this, then it disconnects. As long as the lock file is owned by the correct user and protected accordingly, only that user will be able to successfully communicate with the daemon. Getting a little kludgy, isn't it. I wish OpenVMS has named pipes. We do have other IPC mechanisms on OpenVMS, but I was hoping to get by with as little change as possible.
colin: yeah, that sounds like it would basically work.
Mark: there is meant to be exactly one daemon per user. this corresponds nicely with the fact that the user's mozilla profile is typically stored under "Documents And Settings\%USERNAME%\Application Data\Mozilla\..."
Target Milestone: mozilla1.4beta → mozilla1.4final
I need to understand profile sharing a little better than I currently do. Darin, over in bug 205765 you say: "My assumption was that profile sharing would simply not be a feature available on the ports until sometime later. Anyways, it will not be used by Mozilla until some distant milestone. As is, it is just a feature of the GRE that may find a home in some embedding applications in the future." I thought the current plan was to break "Mozilla the suite" into "Mozilla the components" in 1.5. And when that happens, if I want to run Moz Mail and Moz Browser together then won't I NEED profile sharing? This hardly makes profile sharing a feature that can wait "until sometime later". Or am I misunderstanding what profile sharing is and how it will be used?
Darin, is comment 26 something that some other (currently without a profile sharing solution) platforms could use? Everyone has IP sockets and files, right? Could it be generic enough to be the default implementation for platforms which don't have something better? If so, is this something you could code up quickly? You could certainly do it a lot quicker than me!
colin: so, actually a lot of things about mozilla 1.5 remain up in the air. as i understand it, browser and mail could end up being completely separate apps with completely separate profiles (in the beginning). this is the state of things today. we've been thinking that profile sharing would be important for those two apps since it would enable sharing of wallet data, certs, and other things that may be important to both mail and browser. but, for the most part, it is possible for 1.5 to not use profile sharing. of course, there will be loss of usability relative to 1.4, but that might be a reasonable tradeoff given the complexity of the transition. also, 1.5 is going to be a longer than usual development cycle because of all the scary changes happening. so, i think i'm correct in saying that there isn't a huge hurry at the moment to finish off the IPC service cross-platform. that said, it is of course a good thing that we get started sooner than later ;-) so, as for your thoughts about a general purpose local-TCP/IP solution... i think that that is probably the right way to go as a third IPC mechanism that ports may choose to utilize. like i suspect BeOS probably supports named pipes.. in which case, it can probably share the XP_UNIX impl. so, maybe VMS will be the only platform using this TCP/IP solution. i'm busy w/ 1.4 final stuff right now and have a vacation coming up shortly... so maybe we should hash something out soon. do you want to take a stab at a patch or i can try to whip something up for you to test?
Darin, its good to hear that profile sharing isn't going to be mandatory (if you want a good experience) in 1.5. However, as you said, its better to get started on a solution for OpenVMS sooner rather than later. Changing the sockets to be INET instead of LOCAL doesn't seem too difficult, the part that I'm not so sure about is sending/receiving the randon number which prevents someone from port scanning. If you could give me some pointers as to where in the code would be best to handle that, it would help a lot. Also, what happens if the daemon goes away and there are existing clients? Do these clients detect that the daemon has died and create a new one? What prevents multiple daemons from coming up in such a situation, is it just the directory lock? The new scheme will be a little different since there will be a window whereby the lock file exists but the port/addr/password hasn't been written to it yet, so the clients will have to spin their wheels until that data does appear in the file. Any pointers on how to handle this?
A few notes, not in any particular order. * I'm told the BeOS impl is nearly complete. * a QNX impl should probably be implemented using something specific to QNX (perhaps qnet, i'd have to refresh my memory) The windows impl we have bothers me :) There are cases where a profile could be shared with the wrong user (which the unix version is supposed to not do for security reasons), and there are a bunch of cases where profile sharing will fail for me (these are real for me, and do occur in large installations/institutions). I thought i had mentioned terminal services here, but i can't find any record of it. For this i'm sorry. The topic was mentioned elsewhere under fast user- switching. (comment 25) Windows NT like other systems (unix/x11) allows you to do the following things: 1. Have multiple displays and desktops which can contact eachother. 2. Have multiple gui sessions which can't contact eachother. 3. Run gui processes as other users. 4. Host a profile on a unc \\server\username\profiledata -- Netscape4 used EnumWindows to find itself which means that if you had multiple desktops it wouldn't find itself which would allow you to run multiple instances of it (each needed a distinct profile). -1 FindWindow which is used by the win IPC impl has the same limitation. -- Terminal Services and Fast User Switching. When I use windows 2000 (raistlin), I run a terminal services client on my laptop (tardis) and then run mozilla in it. I'm also likely to run mozilla on raistlin. If some version of mozilla supported profile sharing, then i'd expect my profile to be shared by these two sessions. However there's no common window so it can't possibly happen. -2 With Windows XP, microsoft is more aggressively pushing terminal services, mostly under the fast user switching branding. -- Suppose that a user is running mozilla (timely) and I need to install software using mozilla. I might runas /user:timeless /profile mozilla (this is possible from the gui too). My expectation is that Mozilla will load timeless's profile. However my reading of the ipcdWin code indicates that's not what will happen. -3 -- This last one is a stretch, but not a very big stretch. Suppose that tardis was configured to login to raistlin and load timeless's profile. An ideal profile sharing system would let me share the profile between mozilla running as timeless on raistlin and mozilla running as timeless on tardis. -4 -- Is there a way to implement ipc for windows which doesn't have these limitations? I think mailslots would actually handle all 4. FWIW, 3 and 4 also occur on 9x.
timeless, is BeOS using named pipes, do you know?
>Changing the sockets to be INET instead of LOCAL doesn't seem too difficult, >the part that I'm not so sure about is sending/receiving the randon number >which prevents someone from port scanning. If you could give me some pointers >as to where in the code would be best to handle that, it would help a lot. > >Also, what happens if the daemon goes away and there are existing clients? Do >these clients detect that the daemon has died and create a new one? What >prevents multiple daemons from coming up in such a situation, is it just the >directory lock? The new scheme will be a little different since there will be a >window whereby the lock file exists but the port/addr/password hasn't been >written to it yet, so the clients will have to spin their wheels until that >data does appear in the file. Any pointers on how to handle this? well, for starters, the directory and lock file are created by the daemon. in the case of LOCAL sockets, the daemon also creates the socket (it calls bind). startup is currently not optimal. the client will attempt to connect to the socket, and if that fails it will spawn a daemon process. the daemon process uses the lock file to prevent multiple instances of the daemon in case two are starting up at the same time. the one that loses the race to acquire the lock will simply exit. while the daemon is starting up the client will sleep for 50 milliseconds. when that interval expires, it will wake up and try to connect again. it only attempts to spawn the daemon once, and will keep trying to establish a connection to the daemon periodically. at some point it will give up. there is no attempt made to restart a crashed daemon or anything like that. for users, loss of the daemon is roughly equivalent to loss of the app. once a daemon is started, it has an initial client reference count of zero. upon each accepted connection, the daemon increments its client reference count. if that count reaches zero, then the daemon will exit. care is taken using the lock file to ensure that once the daemon stops accepting connections that another daemon instance would be able to take its place. we probably won't have to worry too much about modifying the client polling since that happens at a higher layer. most of the code we'll care about modifying is in ipcSocketProviderUnix.cpp (not sure yet if we want to create a new file for this or just #ifdef the existing one). finally, there is code in daemon/src/ipcdUnix.cpp that we will need to modify. one big thing to keep in mind. to avoid a race condition in the multiple daemon problem, we currently never delete the lock file. (we depend on the typical /tmp cleanup cron jobs that exist on most systems; most linux distros anyways.) this is not exactly optimal, but it greatly simplifies the locking, and it seems to be the norm for many applications on my linux box anyways. anyhow, because of this, you probably don't want to store the port number and secret key in the lock file. instead, you probably want to store it in a separate file next to the lock file. before shutting down, the daemon should probably clear this file. i think it should be able to do that before releasing the lock. if we crash, however, we might end up leaving around stale info. that would be bad since if another process were running on that port, we'd potentially send out the secret to the wrong process. we could help minimize that by requiring the daemon to send a secret as well or something like that. i still need to think it over some more. darin
timeless: >* I'm told the BeOS impl is nearly complete. great! >* a QNX impl should probably be implemented using something specific to QNX >(perhaps qnet, i'd have to refresh my memory) why? surely it supports at least TCP/IP, in which case it can share the impl we are developing for OpenVMS. >The windows impl we have bothers me :) >There are cases where a profile could be shared with the wrong user (which the >unix version is supposed to not do for security reasons), and there are a bunch >of cases where profile sharing will fail for me (these are real for me, and do >occur in large installations/institutions). > >I thought i had mentioned terminal services here, but i can't find any record >of it. For this i'm sorry. The topic was mentioned elsewhere under fast user- >switching. (comment 25) > >Windows NT like other systems (unix/x11) allows you to do the following things: >1. Have multiple displays and desktops which can contact eachother. >2. Have multiple gui sessions which can't contact eachother. >3. Run gui processes as other users. >4. Host a profile on a unc \\server\username\profiledata >-- >Netscape4 used EnumWindows to find itself which means that if you had multiple >desktops it wouldn't find itself which would allow you to run multiple >instances of it (each needed a distinct profile). -1 > >FindWindow which is used by the win IPC impl has the same limitation. >-- >Terminal Services and Fast User Switching. > >When I use windows 2000 (raistlin), I run a terminal services client on my >laptop (tardis) and then run mozilla in it. I'm also likely to run mozilla on >raistlin. If some version of mozilla supported profile sharing, then i'd expect >my profile to be shared by these two sessions. However there's no common window >so it can't possibly happen. -2 the "profile sharing" feature, despite its name, is not meant to allow two instances of the same application access to the same profile instance. it is meant to support a suite of applications (different executables) sharing the same profile data. e.g, standalone mail and browser. the problem with multiple instances of the same product is that the profile will actually be partitioned into shared content and app specific content. the app specific content will contain the non-shared data. today, that includes everything but the set of shared prefs. the profile lock that exists today will be moved into the per-app directory. so, what you are trying to do here is still (unfortunately) going to require a separate profile just as it does today. way way way in the future when we maybe have everything shared, we might be in a position to support a fully shared profile. but that goal is so distant at this point. >-- >Suppose that a user is running mozilla (timely) and I need to install software >using mozilla. I might runas /user:timeless /profile mozilla (this is possible >from the gui too). My expectation is that Mozilla will load timeless's profile. > >However my reading of the ipcdWin code indicates that's not what will happen. -3 hmm... i'm not sure i completely follow your example here. can you please spell out the steps more completely. i don't understand the arguments you mentioned... or at least i don't get what application would have those areguments passed to it. please clarify so i don't misunderstand your point. >-- >This last one is a stretch, but not a very big stretch. Suppose that tardis was >configured to login to raistlin and load timeless's profile. An ideal profile >sharing system would let me share the profile between mozilla running as >timeless on raistlin and mozilla running as timeless on tardis. -4 >-- yeah, might be nice, but that's not a goal. we are really mostly concerned about supporting an app suite run as a whole on one desktop under one user. that is the primary goal. i don't have the means to test anything else. if you want to implement an alternate IPC solution for windows, then by all means feel free. patches are always welcome. darin
The current code for IPC builds under BeOS, but, I am not completely sure on how to test it, though, I admit, I haven't looked into testing it too much yet, but I will be soon. It uses the Unix code for its implementation. I do have, however, the beginnings of a BeOS implementation based on BMessages, which, is a LOT simpler than the Unix impl. I stopped working on it, once timeless got the Unix code building under BeOS. I may try to complete it at somepoint anyway.
I see there are some test modules. Do they actually build and work?
login as timely (mortal) run mozilla as timely suppose java isn't installed, but needs to be, and needs to be done by an admin runas is like sudo. it lets you run a process as another user. (requires auth) runas mozilla as timeless (power user) with profile the expectation is that the mozilla launched at this point would access the profile of the user which ran it (timeless), not the profile that happens to be running (timely's). That should be enough to describe the problem, but unfortunately because of the fact that the current impl is only for sharing a profile among unlike applications, i'll have to make one modification: for some reason timeless runs mozilla-browser first to install something. timeless doesn't close it. timely runs mozillamail. profile sharing kicks in and gives timely access to timeless's mail prefs, possibly its accounts. (this depends on how passwords are handled, both by profile sharing and by timeless - did timeless configure mozilla to know the mail passwords?) the use of timely/timeless is to make the situation hypothetical. you could read them as darin/administrator, or darin/root. as for lack of means, i'll give you a url for switcher so you can at least test multiple desktops. about QNX,... well, it depends on the goal. if the goal is as you're describing it and not as i envision the feature or as it could be in the future, then it's mostly pointless. QNX6.2 can simply use the domain version, and anyone else can simply have a profile MDefault for mail and a profile BDefault for browser and be done with it. Do you have a list of preferences for which the user gains some benefit when they're shared between distinct applications? To me this seems like a very large amount of effort for a very limited and entirely unknown win. Where's the problem description and where are the design docs? -- Colin: I'm told that BeOS is using BMessages. -- Back to my problem scenarios in windows. Suppose I have one profile and one account on a terminal server. suppose i login twice, the first time i run mozillaBrowser the second time i try to run mozillaMail. Since i originally configured my profile as owning my mail, i'm now locked out of my mail for the foreseeable future(probably until 1.8) because we decided to use profile sharing with this implementation instead of simply forking unrelated profiles for unrelated applications. It seems to me that I'd be much happier having a profile for mail and a profile for browser. And no, your average me doesn't get a choice, profile sharing if implemented would only show a profile manager dialog after the first profile data was locked, not when the user first configured mail and browser. Forking has the additional benefit of not burdenning a Browser with pref data for a mail client and vice versa. (And it's a great opportunity to discard unused legacy prefs.) As for the current code that builds on BeOS, that's supposed to just build enough so that it can return a failure message if something tried to use it. I don't think it would actually work.
> Do you have a list of preferences for which the user gains some benefit when > they're shared between distinct applications? > > To me this seems like a very large amount of effort for a very limited and > entirely unknown win. Where's the problem description and where are the design > docs? Now we're getting somewhere. Startup time is already an issue on most/all platforms. Profile sharing will adversely affect startup time since we have to fork a daemon, wait for it to fire up, and then communicate with it. I don't think people are going to want a slowdown, not unless there's some other huge benefit for them. And at this point, I don't see it. Add to that the fact that if the daemon dies then all the apps are toast, and I think you have a "feature" that no one is going to want. So tell me again, why do we need this? What are the benefits?
You want to use TestIPC to verify that things work. In a debug build enable the IPC_LOG_ENABLE environment variable and check the output (against a build from another unixy platform). the test code should all work. >Add to that the fact that if the daemon dies then all the apps are toast, and I >think you have a "feature" that no one is going to want. if the app dies, the app is toast. what's the difference if the daemon is the one to die? anyways, the app will continue in some manner... maybe the users shared settings will either not be persisted or not be accessible in some manner. it shouldn't be looked at any differently than if mozilla crashed. we don't try to recover from a mozilla crash, right? >So tell me again, why do we need this? What are the benefits? please see the documents on profile sharing... IPC is a feature that supports profile sharing. in addition it can be used to support remote xpcom, explicit discovery of other apps on the system under generic names like "browser", "mail" or "addrbook". it helps solve a lot of problems that i anticipate will come up once the moz apps are split up. the profile sharing docs are here: http://www.mozilla.org/projects/embedding/profileSharing/ there are many many things that we need to share above and beyond prefs. true that is all that is currently working, but we needed to start somewhere.
paul: are you sure you want to maintain a fork of the IPC code specifically for BeOS? is it really worth it if UNIX domain sockets work? timeless: while true you could use this IPC mechanism to have two user accounts (with access to the same GUI) share information, that does not automatically mean that the profile sharing system will have user A access user B's profile data. in fact, the IPC daemon is capable of supporting multiple profiles. each application when it starts up is going to tell the daemon (actually the transaction manager in the daemon) that it is interested in changes for specific "queues" which really represent specific files on the system. so, in your example the runas command would indeed use the proper profile.
darin: No, not really. I had started work on a BeOS impl. before I knew timeless was working on this. If the UNIX socket code works under BeOS, I don't see a point in using the work I started.
err, let's try to be clear about this... i don't think classic BeOS has domain sockets (google showed random configure scripts list QNX and BeOS together in that category). My changes enable ipc to compile (presumably) without any functionality. It's a stopgap so people don't have to add a flag --disable-whatever while they wait for Paul to write the BMessage impl. Darin: I've read those pages. I still don't see any benefit. We have lots of security concerns about mail and cookies. It seems to me that *not* sharing cookies between mail and browser would be a *good* thing. As for cache, I'm not sure how often people get large amounts of content via email which requires them to use a cache. If it happens a lot then I think I'd want to worry about the state of the world. So here's a list: prefs - most of the preferences are either dead or unrelated to a given application as such I'd want to fork prefs and only migrate relevant ones. bookmarks - I don't think people need them outside of browser. I can see uses for them, but we never implemented them. history - Mozilla/5 hasn't had the ability to handle 'alt-left' in recent memory. I used this feature a lot when I used Netscape 4's Messenger. Since the feature didn't make it into the new world, I have to conclude that it wasn't really important to anyone, which means that at least one kind of history wasn't useful to mail. (That's session) - The other kind of history (global) is like cookies, we support it, but it probably doesn't add much value although with css it allows certain privacy attacks, and if people really want the benefit of global history they'd probably benefit from loading the url in the browser of their choice. cookies - See various bugs on cookies from mail. I don't think I know of any good uses for cookies in mail. A distinct cookie jar for mail seems better to me. plugins - I don't need plugins in my email. I suppose some people might.* I'd rather see plugins be a browser only thing. like history if they really want the benefit of plugins then we should enable them to load the email in a browser sandbox. * I'd love to hear a justification for supporting plugins in mail, but that's offtopic so it can be made privately. password manager/form fill - Yes both mail and browser have forms, but do they actually need to share any of their form data? in fact IMO the user interface for the two things should probably not be the same. And the data being stored is generally distinct. certificates - This is the only item where i see some use for a daemon, and in fact PSM1 was such an animal. The old code probably still exists, although people didn't like it much. - I'm not sure how useful this item is either. If you receive a certificate for your web server in email, then you can either save it and import it into your browser, or open it with your browser. In fact, such a certificate would probably be for a web server, not a browser... - If you receive a certificate for your email account from a web server then you can save it and import it into your email client, or open it with your email client. -- You have to do this anyway if your client isn't some GRE item. Again, what problem are you really trying to solve and do you really see it as a problem worth solving in this manner? A daemon which actually let me run multiple Browsers against a shared cache/ cookie/history profile might be useful, but that's clearly not in the current cards. > IPC mechanism to have two user accounts (with > access to the same GUI) share information, eek. i'm pointing out that by default it looks like this bleeding *would* happen. > that does not automatically mean that > the profile sharing system will have user A access user B's profile data. It won't. the profile sharing system will have one of A or Bs data, and will improperly give that data to an application which should have gotten data from a different profile which should have been managed by a *different* daemon. > so, in your example the runas command would indeed use the proper profile. I tried to make this clear. w2k user:timely. has one mozilla profile 'default' w2k user:timeless. has one mozilla profile 'tluafed' The first sharing application runs as timely and starts sharing 'default'. When an application run as timeless on the same desktop starts, it finds timely's daemon and asks it for profile data ('default'). There's no reason for the sharing application running as timeless to know that the daemon it found for 'default' is for the wrong user (timely) / profile (something that is not 'tluafed'). The code doesn't seem to do any check.
timeless: this is not the place for a discussion about the worth of the current profile sharing plan. if you wish to discuss that take it elsewhere... like try a newsgroup. i'm not interested in arguing the merits of profile sharing with you in this bug. >A daemon which actually let me run multiple Browsers against a shared cache/ >cookie/history profile might be useful, but that's clearly not in the current >cards. hello! i never said this wasn't a goal. i only said that the inital goal is to support an application suite. do you not understand the concept of small steps? >I tried to make this clear. >w2k user:timely. has one mozilla profile 'default' >w2k user:timeless. has one mozilla profile 'tluafed' > >The first sharing application runs as timely and starts sharing 'default'. >When an application run as timeless on the same desktop starts, it finds >timely's daemon and asks it for profile data ('default'). There's no given what i said, this is incorrect. the second instance of mozilla run by timeless would ask the daemon (run by timely) to share the 'tluafed' profile. think of the profile name as a namespace. each application tells the daemon what profile it will be using. get it? darin
Ok, so what happens when a daemon running as the wrong user tries to make changes to a profile? my point is that the code that looks for a daemon *must* not look for a daemon owner by anyone else. it could screw up permissions (including resulting in encrypted files which the user can no longer access) or simple dataloss if it has the ability to delete a file but not replace it. it's actually possible under windows xp for drive letters to be restricted to a given user's credentials). it could just fail. it could create a profile with the wrong owner.
>Ok, so what happens when a daemon running as the wrong user tries to make >changes to a profile? > >my point is that the code that looks for a daemon *must* not look for a daemon >owner by anyone else. > >it could screw up permissions (including resulting in encrypted files which the >user can no longer access) or simple dataloss if it has the ability to delete >a file but not replace it. it's actually possible under windows xp for drive >letters to be restricted to a given user's credentials). it could just fail. >it could create a profile with the wrong owner. only a broken application could fall into this category. it won't even be possible for a user to make one of the mozilla apps behave this badly unless of course the second user truly has access (file access) to the first user's profile. but, even then... the user would have to explicitly add the other user's profile to the mozilla profile registry. so, i really think this is a non-issue. clearly both user accounts are under the control of the same human being or else you'd be talking about a breach of security in windows.
timeless: let me spell it out with an example... consider these two user accounts (Win32 profiles): \\Host\UserA \\Host\UserB mozilla applications are going to look in \\Host\%USER%\Application Data\Mozilla\registry.dat to find the list of profiles belonging to %USER%. mozilla apps will only select a profile from that set. therefore any profiles belonging to UserB will not be accessible to UserA unless one hacks the registry and gives UserA sufficient file permissions to access profiles under \\Host\UserB\. make sense?
Paul, BeOS still crashes because of IPC if --disable-profilesharing is left out of the mozconfig. Build attempt 5-16-2003 using current cvs checkout.
Well, I have most of IPC implemented for BeOS. Currently, there is a crash in ipcStringList, when the test tries to run a query by name. I am doing a full update of my tree right now, and will be doing a full re-build. Once done, I will finish off the port, and submit my patch. If the current code in CVS does not work, well, just wait until I submit my patch, as I see no point in me fixing anything w/o a proper impl.darin:While working on the port, I noticed that in the ipcMessage class, the WriteTo and ReadFrom methods can only be called once per instance. I guess that makes sense for ReadFrom, but, for WriteTo, shouldn't the mMsgOffset be reset, once the write has been completed, so, the method can be called a second time? Or, I could be completely missing something. ;-)
It seems I getting the make errors on older src. I pulled todays src, 20030518, and MozFB compiled without an error and the browser works well. Sorry to have caused any problems.
Ok, I finished off an initial port to BeOS. The TestIPC program runs, and seems to be successful, though, I am not completely sure. Plus, some of the code in the test is commented out, which, keeps the TestIPC programming running in a loop on the event queue. I do have a question though, before I submit a patch: Will there be only one client per application instance? In other words, would Mozilla, Firebird and Thunderbird, if setup to use IPC, only create one ipc client each for a total of three client instances? Or, could, say, Mozilla create multiple instances of the ipcClient?
Paul: ipcClient is just a class representing each client connection, and each application need only establish one connection to the IPC daemon. so, in your example there would be a total of 3 ipcClient classes allocated.
That was my guess, but I wanted to make sure, as my code would require some additional changes if it were any other way. I should be submitting a patch soon.
Whiteboard: [adt2] [ETA Needed] → [adt2] [ETA: June 12, 2003]
retargeting to 1.5 alpha... remaining work is mostly cleanup and moving the code onto the trunk. 1.4 final can be happy pulling the IPC branch i think.
Target Milestone: mozilla1.4final → mozilla1.5alpha
Ok, here is a BeOS impl. for the IPC mechanism. Client: Creates a BHandler and attaches it to the current be_app to process messages coming from the daemon (had to modify TestIPC.cpp to have it spawn a BApplication, like nsAppRunner.cpp in xpfe/bootstrap) Daemon: A simple BApplication for receiving/sending messages to/from clients - spawns a BMessageRunner to periodically send Purge messages to itself for removing stale clients Currently, when the last client is removed, the ipcLockModule crashes the daemon in ipcLockModule_ClientDown while enumerating the hash. Not completely sure why, yet, but will investigate Also, the daemon creates an entry on the DeskBar (do to the fact that it is a BApplication), which, I would like to see if I can prevent from happenning. Other than that, it seems to work, at least, the TestIPC doesn't complain about anything.
This fixes the DeskBar issue I mentioned in the last patch by adding a resource file for the daemon, which indicates that the app is background only. There still is an issue with the Test crashing, though, sometimes it works, sometimes its the daemon, and sometimes the TestIPC app itself. This indicates to me that there is a threading issue involved. One place I can think of, is that the Client's MessageReceived code is running in the BApplication's thread, so, for the client, we will need a way to have the BApplication communicate with the proper thread within the test. This will also be needed once Mozilla/Firebird/etc. all become actuall clients, and this code is used. I am still unsure about the daemon crashing, though, as there is only one thread for the daemon ever spawned (everything runs in the daemon's BApplication thread)
Attachment #124132 - Attachment is obsolete: true
bumping target milestone... not sure what the real target for this should be.
Target Milestone: mozilla1.5alpha → mozilla1.5beta
Can someone confirm that having IPC is NOT required for 1.5 (no significant functionality will be lost). This is what I was told a couple of months ago, I just want to make sure that it still holds.
colin: like i said in my previous comment, i don't know what the real target of this is or should be. it doesn't seem like profile sharing will be in use by firebird and thunderbird during the mozilla 1.5 milestone, but i could be wrong.
this is off the radar now... it doesn't look like firebird and thunderbird want to share profile data. -> future
Target Milestone: mozilla1.5beta → Future
This may make a comeback for cert-sharing among the 'birds, unless someone makes Thunderbird an add-on to Firebird that runs in-process. We'll want something for certain customers who use both 'birds and care about PKI. /be
why not go back to psm1 ;-?
timeless: because PSM1 was slow. all data was passed over the IPC connection. in the case of sharing certs, all we really need to do is share the certs. NSS is already setup to optionally access the cert db through a special interface. all we need to do is implement that interface in terms of the ipcIService and implement a module for the IPC daemon that access the .db file(s).
sorry, I didn't follow the profilesharing thing in the past. According to the bugs and the discussion profilesharing is not ready yet? So Moz 1.6 actually don't use it? If so, why are the components in mozilla.org's packages? Is it possible to build mozilla with --disable-profilesharing without loosing features at this time?
> sorry, I didn't follow the profilesharing thing in the past. > According to the bugs and the discussion profilesharing is not ready yet? right, it is not ready yet. > So Moz 1.6 actually don't use it? right > If so, why are the components in mozilla.org's packages? good question. we don't need to be shipping the components; however, they are relatively small :-/ > Is it possible to build mozilla with --disable-profilesharing without loosing > features at this time? yes i think firefox is built with that option.
FYI ports maintainers: there is new discussion about profile sharing going on again. It might very well translate to enabling some of the profile sharing implementation in an upcoming milestone.
(In reply to comment #64) > NSS is already setup to optionally access the cert db through a special > interface. all we need to do is implement that interface in terms of the > ipcIService and implement a module for the IPC daemon that access the .db > file(s). I'm interested in this; where can I find information about this NSS interface?
chpe: you should talk to wtchang.
Assignee: darin → nobody
Status: ASSIGNED → NEW
Priority: P1 → --
Target Milestone: Future → ---
Oh hell, why do you alway make such easy things that complicated ?! Why not simply utilize an the widely supported OS feature called "filesystem" ? Nearly all filesystems support locking - for those which dont, dot-locking should do the trick. The key is to use an well-suited storage format, which models every autonomous record (ie. an bookmark) as its own inode. Concurrent access (between several applications as well as different users) would be as trivial as things like bookmarks from external sources, ie. collaborative bookmarks or rss-feeds. By using an an (separate) userland filesystem layer, those things could simply be mounted-in. I really suggest you to do some little studies on how Plan9 handles those things. It's the perfection of good-old Unix' philosophy "evrything's an file". IMHO, 9p2000 would be an good mechanism for talking to the filesystems: An simple userland client library handles the connections 9p2000 servers and supplies an clean and simple API for evrything else. On application startup, we run an init-routine which mounts the required datasources and starts servers when necessary. After that point, we just use an filesystem - nothing more. Bookmarks, Cookies, Certs, etc are all stored in that filesystem. If someone wants some non-standard setting (ie. get profile data from some server like ldap, collaborative bookmarking, rss-bookmarks, ...), all he has to do is choose the right 9p2000 server (or write one if necessary) and mount it in. All these problems are immediately off the scope of mozilla at this point.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
QA Contact: ashshbhatt → ipc
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: