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

[Havoc Pennington]

On Fri, 2005-11-11 at 17:05 +0000, Robert McQueen wrote:
> 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.

Explain what you mean by this case that's different from the two I
listed - i.e. what sort of service, concretely.

Hmm. We should probably map this out. For a text editor, we want:
 - you can only run one Emacs or one GEdit, but you can run 
   both apps at once; let's call Emacs and GEdit two 'brands'
   of text editor
 - if either is running you have the generic TextEditor service,
   regardless of order of start/exit

So for this you want "queue" but "don't replace"

I'm not sure this is right; I think it might be possible that if I set
Emacs as my default text editor, it should always own the generic
TextEditor service and no other editor should ever even try to own it.
In that case the queuing behavior just doesn't make any difference.

For a screensaver it's a bit different, you want:

 - only have one screensaver running, regardless of brand; 
   so you don't want both xscreensaver and kscreensaver or something

Here queue works if all screensavers exit when they aren't the primary
owner, but !queue is more natural. You don't want to allow replacement.
(I think we all agree that allowing replacement won't be a common case,
since apps have to be ready to deal with it)

Blah. This is why I'm very uncomfortable going 1.0 without real desktop
application usage.

> no signal watching to cope with a)
> losing the name later or b) not actually having it and getting it later.

Two questions here.

1) I don't understand why a service cares about this unless it wants to
exit. Just sit there and wait for requests. There's nothing special to
do. Give a concrete example?

In fact I *believe* the original reason I implemented the queue feature
was so apps would not have to sit there and monitor the bus to see when
the current owner exited. i.e. the point of the queue is that you don't
have to do anything if you just want to say "I'll provide this service
whenever nobody else is providing it"

The other thing about the queue feature is that it removes a certain
kind of race condition by leaving no time gap between the old owner
leaving and the new owner taking the name.

2) If you want to exit if you don't get the service right away, can't
you do:
  if (reply != REPLY_PRIMARY_OWNER)
    exit(0);
which works regardless of the flags? It seems to me that 
  if (reply != REPLY_EXISTS) 
    exit(0);
is just wrong.

Anyway, can you give a specific example and describe how you would write
the code for the queue and !queue case? I don't have a sense of what
you're saying is different in your code in the two cases.

The above somewhat argues that there's no point even having the !queue
case; we could just always queue, and if you don't want to be in the
queue you just remove yourself ... though there's a weird race condition
here where you could become the primary owner for a brief moment.

> 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

I think the right thing is to behave in the most likely to be right way,
or the way that requires less *application* code to handle correctly. We
can talk about what that way is.

>  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

That probably makes sense, but we do need to be sure to get *all* the
planned ABI breaks ... a few more small ones might trickle in but we
should try to avoid any blatant oversights.

Havoc