Activation design draft

[Havoc Pennington]

On Mon, 2004-01-19 at 08:32, Richard Hult wrote:
> > 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.

What is the purpose of implicit activation if not to avoid round trips?

Otherwise you can just do the activation synchronously and then send
your messages:

 if (!activate ()) /* synchronous */
   error;
 else
   send_messages ();

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

This isn't different though. If an executable provides services Foo and
Bar, then it always creates those services on startup; it doesn't matter
what name it was activated as.

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

I like xml myself for this, but the .ini has some argument in terms of
familiarity to dcop users.

Havoc