Activation design draft

[Richard Hult]

mån 2004-01-19 klockan 08.45 skrev Havoc Pennington:
> Hi,

Hi,

> 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.

Yeah, that was our other suggested way. It does indeed make more sense
with regards to round trips.

> > 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.

That's a somewhat different problem than what we were trying to solve:
Avoiding to launch two instances of an executable when two clients
activate two different services that are provided by that executable.

It might be that such cases are very rare. Having only one service per
executable is probably more common, and the examples we used should
probably use several interfaces instead of several services.

> File format - right now it's a .ini-type of thing, do we want to do
> XML instead?

I don't have a personal preference, but the reasoning was that the bus
configuration is XML, other things like the new MIME files are XML, the
suggested split of properties would make the file look less like a
desktop file, could be validated with e.g. DTD, and the aggregated cache
file would contain all service entries so XML could fit better.

/Richard

-- 
Richard Hult                    richard@imendio.com
Imendio                         http://www.imendio.com