more on object/method change

[Philipp]

Hi all, hi Havoc,

[this is my first post to this list]


[snip -- many good ideas which i'm too tired too comment in detail]

>I wonder if it's too much magic if we allow the interface to be
>omitted, in which case the destination interface would be taken
>to be the same as the service name:
>
> service = org.freedesktop.Prefs
> method = GetValue
>
>implying interface = org.freedesktop.Prefs as well.  This is mostly
>just a bandwidth-saving hack I guess.
>
I think that would be a bit confusing for the user.


>Another question is how do signals work. To "emit" a signal we want to
>invoke the connected method on the receiving objects.
>
>Say I send a signal with this information:
>
> emitting object = 0x3491
> emitting interface = org.freedesktop.Prefs
> signal = ValueChanged
>
>Here the "interface" field is the interface that emits, not the
>interface the message is destined for.
>
>Without the message bus involved, the peer application would keep 
>an in-process list of object instances interested in the above 
>signal; would that list map from the entire (instance, interface,
>signal) triplet to (instance, interface, method) triplets?
>  
>
Back in the days when I programmed Object Pascal (specifically
Free Pascal), there was an event system which had the basic
assumption signal name == method name. (Not exactly like that,
actually you hardcoded the signal name you'd want to receive with
the method signature declaration, but the above is basically
what it boiled down to.) This approach always seemed to me
rather intuitive and simple, because a signal connect would
only have the paramters <emitter object, signal name, target object>,
and you'd have appropiately named methods, similar to the
getter/setter methods for properties so popular these days
with many languages.

A different approach to look at this would be that any
defined signal has an associated interface, which any
interested target object must implenent.

Granted, this is not quite as flexible as the approach
including method names, but i don't see where one
would actually _need_ the additional flexibility. Also,
it is easier to use for developers and less message
processing overhead.

To stay with the terminology you used above, one would
have to handle <service, instance, signal> to
<service, instance> association, with optinally an interface
instead of an instance (for the cases where you don't know
the instance you want yet).


So much for now. G'night. :)
  Philipp