Re: oaf patch to keep servers in process group

[Maciej Stachowiak <mjs noisehavoc org>]

On 22Jul2001 09:44AM (-0400), Havoc Pennington wrote:
> 
> Maciej Stachowiak <mjs noisehavoc org> writes: 
> > Is there any way you can see if it at least compiles on, say, FreeBSD?
> > I'm always wary of making these kinds of changes and then being flamed
> > by BSD fans. If there's no convenient way for you to do that, just go
> > ahead with it.
> 
> If anyone on the list w/ freebsd wants to volunteer to try, that'd be
> great. I don't have it myself.
> 
> Why don't you just try on your MacOS X box though? That's an ancient
> crufy BSD in there isn't it? ;-) /me runs

I've been avoinding so much as checking out GNOME code on my work box
to avoid the possibility of legal contamination.
  
> > OAF lets you register your server as per-display rather than
> > per-system at registration time. This does not require additional oafd
> > instances, although the way it works is a bit of a hack. 
> 
> How does it work? I haven't seen any code in oaf that looked
> display-related. 

The convention is to register as "displayname,oafiid" instead of just
"oafiid"; oaf checks for a server registered on your display in
preference to one registered display-independent.

I guess you are actually registering per machine/display combo rather
than per display, since the goal is to avoid problems with one server
handling multiple displays rather than multiple servers on one
display.

> Elliot says he wanted to add a "registration location" on the
> display instead of in /tmp at one point.

I think the whole registration location thing is hopelessly
overengineered.
 
> > There's no way to make servers per-session because I can't think of
> > a case where it matters. You can't run two different sessions on the
> > same display at the same time, as far as I know.  And even if you
> > could, it seems to me it would be fine to share out-of-proc servers
> > between processes in the two sessions.
> 
> You can have multiple sessions on one display; the usual case where
> this happens is that I remotely display an app from session A on the
> display where most apps are in session B.
> 
> IIRC it's also completely allowed by the SM spec to have 10 session
> managers managing different sets of your apps, though why you would do
> that I have no idea.
> 
> The other issue here is that a display can have several sequential
> user logins without reset, gdm used to do this, it may always reset
> the display now though. So logically you want your server lifecycle
> tied to a user session not the display lifetime.

Regardless of all this I can't imagine why you would want to register
multiple servers of the same type distinguished by different sessions.
Can you name a specific reason this would be useful? CORBA servers
really should not register with the session manager anyway.
 
Regards,

Maciej