Comments (11)
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.
Related Issues (20)
- Building statically but linking to a shared library results in linker error HOT 2
- CanCallMethodSynchronouslyWithoutAnEventLoopThread hangs since 1.3.0 if built by Clang HOT 8
- Disable sd-event in release/v2.0 once #358 is merged and release/v2.0 rebased HOT 2
- Support for creating tcp connections via sd_bus_set_address or sd_bus_set_fd HOT 2
- pkgconfig fails to resolve dependencies
- Tests installation path should respect install prefix
- Allow moving ProxyInterfaces HOT 2
- Error when implementing ObjectManager on System Bus Connection
- Sporadic missed NameAcquired signal if requestName called after enterEventLoopAsync HOT 2
- doesn't notice signal without method call HOT 7
- Serialization of maps into structs and vice versa
- Manually configuring choice of sd-bus implementation library HOT 4
- [org.freedesktop.DBus.Error.ServiceUnknown] The name com.example.test was not provided by any .service files HOT 5
- why: uncaught exception of type sdbus::Error ([org.freedesktop.DBus.Error.FileNotFound] Failed to open bus (No such file or directory)) HOT 1
- Crash when running a connection event loop HOT 2
- How to do IPC between two process by sdbus::createServerBus and sdbus::createDirectBusConnection
- Allow arbitrary structs in an sdbus interface HOT 4
- Support for serializing `std::variant<>` types HOT 2
- Can't receive signals by ObjectProxy at client side (but see this signals at dbus-monitor) HOT 2
- SEGFAULT after generated proxy move HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sdbus-cpp.