about signals

[Olivier Andrieu]

 Havoc Pennington [Fri, 28 May 2004]:
 > On Thu, 2004-05-27 at 19:09, Olivier Andrieu wrote:
 > > The way I see it, services are not conceptually different from object
 > > paths and interfaces, it's part of the naming of a remote piece of
 > > code: service designates an application (process), the path designates
 > > an object (whatever that means in the language the remote application
 > > was written in), the interface + member name designates a method in
 > > the object. 
 > 
 > This isn't right though. The reason a well-known service is different is
 > that a base service name, object path, and interface uniquely and
 > exclusively identify an object. There are not "aliases"
<snip>
 > If you do this then services become "directories" or "folders" for
 > objects; in fact a service is pretty equivalent to prepending another 
 > element to the front of the object path.
 
Yes.

 > > and we would have:
 > > DBusMessage* dbus_message_new_signal        (const char  *service,
 > >                                              const char  *path,
 > >                                              const char  *interface,
 > >                                              const char  *name);
 > > 
 > 
 > 
 > _Which_ service?

it depends on the emitter object. If OpenOffice.org owns the
TextEditor, the SpreadSheet and the Presentation services, then
objects emits from one of these contexts. Well-known service names
describe what the app do and object are naturally linked with those
actions.


 > Services are intended to be used like X selections, they are a resource
 > that the app can acquire to become "the" text editor rather than "a"
 > text editor.
 > 
 > So even if I know that this signal is only used via the TextEditor
 > service, there may be 5 apps all trying to claim the TextEditor service,
 > and I may or may not own it. I shouldn't be unable to emit the signal in
 > that case, since someone may still want to interact with my specific
 > text editor application - perhaps for example GEdit has _the_ TextEditor
 > service, but OpenOffice.org also supports the same interface with the
 > same signals. Or maybe 3 instances of GEdit are running, or one GEdit
 > and one KWrite. You can't stop emitting signals when you don't own the
 > service.

OK I see, signals should still get through even if the app has lost
service ownership. But imagine this: the app talks to GEdit via
g_proxy_for_service("TextEditor" ...) and then OpenOffice.org steals
the TextEditor service. Now signals from GEdit wouldn't reach the
proxy because of the service tracking; the app should have used
g_proxy_for_service_owner() in this case.  But I wonder when one
should use one or the other. Is this really up to the app to decide
this ? It also depends a lot on the service owner (wether it used
PROHIBIT_REPLACEMENT, etc.)

Also (slightly different topic) how does this interact with activation
? If nobody owns the TexEditor service how would it be activated ? I
mean, this is complicated, the user's preference would probably have
to be checked. The activation file for GEdit would specify
org.gnome.GEdit not TextEditor, no ?

 > Also, a concern I have is that with DCOP people are frequently
 > auto-exporting remote interfaces for lots of objects. In that case
 > there's no sensible service name.
 > 
 > >  A method call never needs to use a unique name as
 > > its destination service: the way an application learns about unique
 > > names is through service announcements messages or activation
 > > messages. So it's always linked with a real service name.
 > 
 > Ideally, we would *always* use the unique name once we know what it is.
 > 
 > To be semantically clean we would do:
 > 
 >    unique_name = get_owner (well_known_name);
 > 
 >    invoke_method (unique_name);
 > 
 > The reason this gets reduced to:
 >  
 >    invoke_method (well_known_name);
 > 
 > is 1) an optimization to avoid round trips and 

except that the service tracking by proxies sort of nulls this since
the first thing the proxy would do after creation is ask for the owner
so as to be able to connect signals.

 > 2) because sometimes you don't care if the owner of well_known_name
 > is not the same as it was last time you performed a method call on
 > that name.

yeah but how do you know it's OK not to care ? 

 > >  > Remember signal emission/listening is supposed to work without a bus
 > >  > daemon at all, in the context of just a direct 1-to-1 connection.
 > >  > In that scenario the equivalent of keying your listener code off the
 > >  > service would be changing behavior depending on whether you connected to
 > >  > "host", "host.bar.com", or "localhost" to establish the connection.
 > > 
 > > I'm not sure I understand this. Services are about the bus routing
 > > and/or dropping messages, i.e. all service-dependent handling is done
 > > in the bus dameon. In the 1-to-1 case messages alway go directly to
 > > the peer. 
 > 
 > In the 1-to-1 case requiring someone to specify a service in order to
 > emit a signal would not make any sense.

It's just a matter of making the service optional in the API (ie
accept NULL in C).

-- 
   Olivier