--===============0667966815==
Content-Type: multipart/signed;
  boundary="nextPart1799601.zxXefKZCff";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1799601.zxXefKZCff
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Em Tuesday 13 November 2007 08:56:15 Wang Jun escreveu:
> Hi Thiago Macieira,
>
> Thank you for your reply. but I kind of find exception to
> what you said. check below.

Please reply to the list. If you mail me directly, I might ignore the messa=
ge=20
because I don't know the answer (or am busy), but other people may be able =
to=20
answer.

> On Tue, 2007-11-13 at 08:20 +0100, Thiago Macieira wrote:
> > Wang Jun wrote:
> > >I am using D-Bus C API. Is it possible to make sure the well known nam=
es
> > >are returned when dbus_message_get_sender(msg)
> > >and dbus_message_get_destination(msg) are called?
> >
> > No.
> >
> > get_sender ALWAYS returns the unique name.
> >
> > get_destination returns what the sender chose. It can be either a unique
> > or a well-known name.
>
> can you give a bit more elaboration on this?

Yes.

The sender is set by the bus daemon. It always sets to the unique name.=20
Therefore, get_sender always returns a unique name.

As for the destination, it's set by the sender, so it's what the sender cho=
se=20
it to be. If it set the destination to a unique name, you get a unique name=
=2E=20
If it set the destination to a well-known name, you get a well-known name.

> > >Currently, I am not using any matching rule for listening on dbus as
> > >I want to catch both method_calls and signals. So I use the
> > >  dbus_message_get_sender(msg) to check the sender and then call
> > >the relevant subroutines. But the function returns unique names
> > >instead of well known name...
> >
> > That paragraph doesn't make sense. Without a matching rule, you don't
> > receive the message in the first place.
>
> actually I am not familiar with the C implementation inside in dBus.
> But My program does be able to receive both SIGNAL and METHOD_CALLS
> without specifying any addMatch..

I guess that the dbus-daemon has some implicit rules, then. But you should =
not=20
be receiving signals without an add match rule.

Someone else may be able to clarify the behaviour of the daemon in case the=
re=20
aren't any rules set.

> currently I dispatch the call based on interface, path, name..
> But cannot based on SENDER and DESTINATION due to the problem I
> mentioned

You don't want to dispatch based on sender and destination.

If the destination is set (i.e., method calls), then the destination is you=
=20
because you received the message in the first place. Therefore, you don't=20
need to check if the destination is you. You should handle all messages=20
equally.

If the destination isn't set, it's a signal.

As for the sender, you shouldn't treat messages differently based on the=20
sender. You should treat all senders equally.

=2D-=20
=C2=A0 Thiago Macieira =C2=A0- =C2=A0thiago (AT) macieira.info - thiago (AT=
) kde.org
=C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
=C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4 5358

--nextPart1799601.zxXefKZCff
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHOWGcM/XwBW70U1gRAr5uAJ9WemccqMtsDlmvdDAi8Na3aWbw1wCgqRe9
h2o51yG0Pt9LL5UJdZv40/o=
=uu5M
-----END PGP SIGNATURE-----

--nextPart1799601.zxXefKZCff--

--===============0667966815==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus

--===============0667966815==--