Activation design draft
Mon, 19 Jan 2004 02:45:00 -0500
Some late-night thoughts -
I think you missed the point of implicit activation - the main reason
for it in my mind would be to avoid a lot of round trips on application
startup. If you implement it in the client lib, you still have to wait
to hear back about the activation, so you don't save the round trips.
The implementation would basically store a queue of messages on a
PendingActivation and deliver them when the activation is completed - or
return errors for them if the activation fails.
> The bus needs to know if a number of services are provided by
> the same executable, to avoid a race condition when activating two
> services that are provided by the same executable.
This race is unavoidable, given /usr/bin/foo vs. /usr/local/foo type of
things, and simply two different programs that can provide the same
service. The solution to the race I think is simply that one of the
launched executables won't get the service, not to avoid launching one
of them up front - trying to avoid launching one could cause problems
and be complicated.
File format - right now it's a .ini-type of thing, do we want to do XML