Activation design draft

[Havoc Pennington]

On Mon, 2004-01-19 at 21:36, Mikael Hallendal wrote:
> >  if (!activate ()) /* synchronous */
> >    error;
> >  else
> >    send_messages ();
> 
> Yeah, it's easy for synchronous calls but not as easy for asynchronous.
> Also, you might want to send dbus messages from several places in your
> code without having to make sure the connection is up in every place. 
> 

If the code is genuinely unrelated, though, then you can't know the
activation has been requested at all.

I may not understand exactly how you're suggesting it should work.

I think it should be pretty easy to add a message queue to
PendingActivation along with the queue of waiting activators, but I
could be wrong.

> For example, Executable E handles Service A and Service B. When it is
> launched it will acquire both of the services. 
> 
> 1) Client C tries to activate Service A
> 2) The bus execute E
> 3) Client D tries to activate Service B
> 4) The bus sees that E is already pending and puts Client D in the 
>    pending queue.
> 
> So, as we see it, either the bus needs to check that the executable is
> the same as one that is already in the pending queue or we add the
> service provider idea (so that we can match on service provider name
> rather than the actual executable).
> 
> Not sure which way is the better, or will this even be a problem?

I don't think it's a problem, since it's really OK if client D goes in
the pending queue for B, and client C goes in a different pending queue
for A, and both queues are cleared when executable E launches the first
time. The second executable E to start then just exits when it fails to
acquire its services.

It has to work that way, since the user can also just manually launch
the executable at any time, the bus isn't the only possible launcher.

Havoc