Activation design draft

[Mikael Hallendal]

tis 2004-01-20 klockan 02.33 skrev 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 ();

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. 

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

I think you might misunderstand us (maybe because we refer to something
that doesn't need to be handled).

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?

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

It would be great to hear something from the KDE guys about this (and
other things proposed).

Regards,
  Mikael Hallendal
-- 
Mikael Hallendal               micke@imendio.com
Imendio HB                     http://www.imendio.com
Phone: +46 (0)709 718 918