lets do a release! (was: Re: [PATCH] Third and Final (hopefully))

[Robert McQueen]

Havoc Pennington wrote:
> Hi,
> 
> I envision it working as follows:
> 
>  - in the framework libraries, we have KUniqueApplication and a GNOME 
>    equivalent; by default, each binary in /usr/bin basically owns a 
>    service named after that binary and the second time you run the 
>    binary you get the existing process, not a new process. This is 
>    how we be sure only one GEdit is running (but both GEdit and Emacs
>    can run at the same time)
> 
>  - if developers ever manually manipulate bus names to offer a name
>    other than their application name, that would normally use the 
>    queuing mechanism so that multiple apps can offer the same name
>    without "conflicting" or introducing race conditions. 
>    This is how you offer a "TextEditor" applescript/COM style "scripting
>    interface" - which both GEdit and Emacs might support.
> 
> If those are the two use cases, then most apps probably use both, but
> the second one is the one where the app author is having to deal with
> it.

These use cases for queueing are fine, and there may be others, but for
the /not/ queueing cases a common one which we should bear in mind is
service activation. I think this is how many people think of D-Bus,
where a particular program is started by the bus daemon to provide a
service, provides it, and then goes away when it chooses. These are
necessarily singletons and no queueing or replacing is ever necessary.

I really do think the flags should called ALLOW_REPLACE and ALLOW_QUEUE,
so that in the case of the lower-level users (ie almost all the D-Bus
programs that exist currently, with a handful of exceptions) they can
expect request_name to either succeed or fail depending on whether or
not they get the name, and require no signal watching to cope with a)
losing the name later or b) not actually having it and getting it later.
The simple case is the default, you call the method and get an answer
that persists, and you need do no more monitoring.

For your use cases, queueing and replacing do need to be invoked, but as
you suggest, a wrapper might deal with these signals for you, in which
case it would also take care of setting the flags.

Despite this detail, it seems we're actually agreed the patch is a good
idea, so I'd like to propose that we do this:
 a) switch NO_QUEUE to ALLOW_QUEUE so we behave in the most simple way
by default
 b) commit this patch along with my bus name releasing stuff
 c) merge J5's outstanding API breaks
 d) release 0.60 (not to be too hasty... :D) to the ISVs who I know are
waiting for it

Regards,
Rob