How to access to sender address about sdbus-cpp HOT 11 CLOSED

I added getSenderName method to the Message class. So now, at the message-level API, you can access that information. Beware that D-Bus peers that don't expose D-Bus services will have numerical sender name.

Anyway, you might want to have your own solution to sender identification, at your level of abstraction, rather than relying on lower level D-Bus approach (which mixes numbers and strings, depending on the process setup). And I don't think adding it as an additional parameter to the RegisterDevice method is wrong. I think it is exactly at the proper abstraction layer -- sender ID and object path are together to uniquely identify the plugged in process.

Adding additional message metadata to the list of parameters of high-level functions is not only mixing of abstraction levels, but creates technical issues. For example, when generating stubs from D-Bus IDL, we need a way to tell which method to generate with that metadata parameter, and which not... The pile of design and technical difficulties overweights the gains, so it doesn't make sense to go on this way.

from sdbus-cpp.

Hey @a1ien , there will now be a sdbus-c++-provided solution to your problem. See #190

from sdbus-cpp.

Hi, there is currently no way to get or set sender address. But adding this functionality (to Message API) should be quite trivial. Would you like to contribute?

from sdbus-cpp.

Hmm... But even if we realize getting the address, how to get access to the Message inside function registered by implementedAs.

from sdbus-cpp.

That is a difficult question. By design, high-level API abstracts the concept of messages away completely and brings D-Bus methods closer to native local functions. There is currently no access to the message from within such high-level functions. And IMHO it ideally shouldn't be. Yes, we are losing some information (the message and its metadata) here, but this is because that information simply belongs to a different, lower abstraction level. sdbus-c++ also provides lower-level, message-oriented API. So a quick and correct approach would be to use that API in order to have access to Message object.

from sdbus-cpp.

Maybe we can specify implementedAs and is's calback registration with type sdbus::Message.
For example
if we write

registerMethod("Method")
.onInterface("iface")
.implementedAs([this](int value){ 
 //do something
 });

it's simple call. But if we can get raw message if write something like this

registerMethod("Method")
.onInterface("iface")
.implementedAs([this](const sdbus::Message &message,int value){ 
// we have access to raw sdbus::Message by message arg
 //do something
 });

For do that we can implement deserialize for sdbus message reference to itself.
Like this?

Message& Message::operator>>(const Message& item)
{
    item = *this;
    return *this;
}

from sdbus-cpp.

Apart from ideal solution, it should technically be possible to implement access to the method call message in a high-level server's D-Bus method implementation, in both sync and async methods. But this needs to be consciously decided and backed by some good arguments...

from sdbus-cpp.

Or if sdbus::Message it's too low level. We can add new type sdbus::MessageHeader with such info and allow sdbus::Message to deserialize to sdbus::MessageHeader

from sdbus-cpp.

Apart from ideal solution, it should technically be possible to implement access to the method call message in a high-level server's D-Bus method implementation, in both sync and async methods. But this needs to be consciously decided and backed by some good arguments...

Your example is what I meant by technical possibility of implementation. However, we need to be very careful, this already seems like messing things up and mixing different layers of abstraction. When a user gets the method call message and method call arguments next to each other, it stops making much sense. It seems like mixing and duplication of information. The user will very likely scratch his head and ask himself: Why do I have method arguments listed additionally here when I can easily get them out of the first argument -- the message itself? Especially when sdbus-c++ already provides message-based API where method call message is provided as an argument of a method callback?

Such confusion of library users is certainly something we don't want to happen. We want to make API simple and clean to help users have simpler life and good sleep :)

But I don't preclude your proposal completely. In order for me to understand your motivation and arguments, can you please be more specific and explain the context of your problem, what are you solving, why do you need sender address, what other message data do you need except that? And, most importantly here, why can't you use message-based API?

from sdbus-cpp.

I want write some "plugin" system. And to register other dbus applications, I wanted to implement the RegisterDevice method, which takes only ObjectPath as an argument. And find out the address of the application simply by the address of the sender.
Of course, you can simply add an extra argument. But then duplication turns out. So, as this data is already transmitted in the message.

from sdbus-cpp.

I would close the issue unless you have other related comments.

from sdbus-cpp.