Re: bonobo activation question

[Bill Haneman <bill haneman sun com>]

On Wed, 2002-08-07 at 11:43, Rodrigo Moya wrote:
...
> I think it should be a system-wide daemon, not a per-user one, since
if
> it's a per-user one, what if b-a-s hasn't been started yet? Also, if
> it's a multi-user machine, with many users connected, it would mean
> having n*2 daemons running (*2 because there would the 'normal' b-a-s
> daemon and the remote one).

Keeping this a per-user daemon would relieve some of the security
concerns, and also map better onto the existing b-a architecture IMO,
particularly for the multi-user cases that are most interesting here.

That doesn't mean that some kind of b-a-s daemon to spawn the per-user
activation servers wouldn't make sense; in fact I suspect that this is
the kind of two-tiered solution that will be required.

-Bill

> That system-wide daemon could just listen on the port, and get requests
> from clients in the form:
> 
> GET OAFIID:GNOME_Whatever USER=rodrigo PASSWORD=mypassword
> 
> then, he could just su to that user (rodrigo), do the normal b-a-s
> activation, and then return back the IOR of the activated object.
> 
> Another possibility would be to have a simple protocol like:
> 
> USER rodrigo
> -> OK
> PASSWORD mypassword
> -> OK
> QUERY repo_ids.has('IDL:Bonobo/Control:1.0') and whatever....
> -> return list of objects
> ACTIVATE OAFIID:GNOME_Whatever
> -> return IOR
> BYE
> -> BYE
> 
> > >  and gets queries from b-a-s clients requiring a remote object,
> > 
> > 	How do you require the remote object ?
> > 
> well, we may need to extend the syntax of b-a-s queries, to support
> that, so that you can just specify the machine, user, password on it. So
> that you can say:
> 
> bonobo_activate_object ("OAFIID:GNOME_Whatever and HOST=host and
> USER=rodrigo AND password=mypassword");
> 
> or something like that.
> 
> Another nice idea would be to get back remote objects when you do a
> query. For that, we could just broadcast the query, and get the results
> back from any machine exporting remote components, so that if you do a
> query in your local machine for components implementing the
> Bonobo/Control interface, you'll get back the local as well as any
> remote object installed on the network.
> 
> For extra security, we could just have a list of trusted machines, as
> you do with NFS, for instance, where you explicitly allow hosts/networks
> to access your exported volumes.
> 
> > >  and just send back the IOR of those objects after having
> > > activated them.
> > 
> > 	Sending the IOR back is easy; how do you activate a remote object, how
> > do you reconcile the remote database of what objects are present and can
> > be activated with what you have locally efficiently etc. etc.
> > 
> the daemon I propose is just a wrapper for the local b-a-s, so it just
> activates objects, returns IORs and quit. The registry of activated
> components would still be part of the 'normal' b-a-s daemon, which would
> be running per-user.
> 
> It's only an idea, so it may be wrong, but it is the easiest and
> cleanest way I see to implement it.
> 
> cheers