[PATCH] Third and Final (hopefully)

[Havoc Pennington]

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.

On Wed, 2005-11-09 at 11:35 +0000, Robert McQueen wrote:
> 
> I don't see this at all. The programmer always has to check the return
> value to their function. To handle being on the queue, you have to watch
> for signals to know if you've actually got the name or not. It seems
> like more work in the queue-by-default case. If you call the function to
> get a name and it says "yes you have it" or "no you don't", this is trivial.
> 

In the "multiple providers of a service"/"text editor" use case, you 
don't need to know whether you got the name. If you didn't, you just
won't get any method calls. But you don't have to do special work for
that. If you later get the name, then you'll start getting the calls.

i.e. not having the name is just the same as nobody bothering to talk to
you. It's not a case that requires special handling.

If you want a unique instance, then yes, you have to know whether you
got the name, so you can exit if you did not. But that's my point - in
the "unique instance" use case you are already writing this code. So the
default is for the case where you aren't having to think about anything,
and the non-default is for the case where you had to write handler code
anyway.

> > Another scenario is "unique application" where if the name is already
> > owned you want to pass on the new windows to open and exit, otherwise
> > you own the name. In this case you want "no queue" / "no replacement"
> > probably. But you also have to write some tricky code and there's
> > probably going to be a library function that deals with it (already is
> > in KDE)
> 
> This is the more common case in my opinion, and certainly this is how
> most current bus users work, with service activation to activate the
> single desired instance. Queueing is a more elaborate scenario which you
> should choose to get into if you wish, hence "no queue"/"no replacement"
> being my suggestion for the default.

Hmm. I think queueing requires writing less code and is easier to deal
with ;-) "single instance" should be *of a particular app* while queuing
should be *of a particular interface* if that makes sense.

Anytime you have multiple possible providers, like OO.org writer and
AbiWord, or GEdit and Emacs, or whatever, then you need to use the
queueing for the name "TextEditor" or "WordProcessor" and you need to
not use queuing for the unique app name like "AbiWord"

Havoc