On Sun, Sep 25 2011, Michael Albinus wrote:

> `dbus-register-signal' checks for the a valid service name, if it isn't
> nil. Usually, "some.service" is not known; in my test
> `dbus-register-signal' raises an error then.
>
> How did you manage to register your signal with that service?

No idea. But the check seems to be not functionnal here obviously.

>>  ((:session "org.gtk.Private.RemoteVolumeMonitor" "VolumeAdded")
>>   (""
>>    "some.service" "/org/gtk/Private/RemoteVolumeMonitor" identity
>>    "‚")))
>
> This entry has a corrupted match rule. Again, which trick brings
> `dbus-register-signal' to accept it? I must implement a counter-check
> for this!

Yes. If you want me to test a patch before committing it, or to run a
debug patch with some printf or whatever, do not hesitate.

>> Then I call unregister it yells:
>> Debugger entered--Lisp error: (dbus-error "Unable to append argument" "\202")
>>   dbus-call-method(:session "org.freedesktop.DBus" "/org/freedesktop/DBus" "org.freedesktop.DBus" "RemoveMatch" "\202")
>>
>> Where the last string is obviously the same as I talked about above. :)
>
> Which is the correct answer, because there isn't a valid match rule. I
> could add a check for a valid match rule before sending the
> "RemoveMatch" message, but I believe this is superfluous, because there
> is exactly one place that match rule is appended. At this place, we must
> prevent wrong values.

Again, be careful on one last thing. I did a couple of tests in an Emacs
session, and sometimes I saw:

method call sender=:1.254 -> dest=org.freedesktop.DBus serial=27 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=ReleaseName
   string "some.service"

And I was *only* testing dbus-register-signal, so there seems to be
still some case or the "(when service …" stuff is doing ReleaseName even
on a signal match.

-- 
Julien Danjou