Are signature_of and in/out operators part of the intended API?

[JohannesSchilling]

[sorry if this is more of a support request than a regular issue, i guess you could phrase it as "please document" instead though]

I have tried to use custom structures as arguments/return value of D-Bus handler methods in my project, like this:

struct MyFoo {
  bool a;
  int b;
};

namespace sdbus {
  template <>
  struct signature_of<MyFoo> {
    static constexpr bool is_valid = true;
    static const std::string str() {
      return signature_of<sdbus::Struct<bool, int>>::str();
    }
  }
}

sdbus::Message& operator>>(sdbus::Message& msg, MyFoo& foo) {
  msg.enterStruct("bi");
  msg >> foo.a;
  msg >> foo.b;
  msg.exitStruct();
}

This makes me able to use MyFoo as parameter to D-Bus methods, but it's not documented anywhere and so i'm kind of wondering if that is intended API surface or more of an accidental internal detail that i'm using here..

[sangelovic]

Good question :) I could probably answer "both"... 😃

This was originally designed to be actually used internally for a limited set of D-Bus types. To carry that intent, it should perhaps have been placed into detail subnamespace...

But your situation of actually "overloading" these constructs for your custom types is actually interesting (I could name it not a design intent but more of a discovery 😃), as it is one way of enabling clients to seamlessly incorporate their custom types in D-Bus API as opposed to the types forced by sdbus-c++ -- but not only structs. Also types of collections may be customized (e.g. std::unordered_map instead of std::map)...

This becoming an official part of public API would mean we have to make sure it remains stable and that it is documented (maybe be related to still open issue #204 ). What we can consider is if we want provide tools that force clients to extend sdbus namespace (now I mean signature_of specifically), or they can do all the extensions without opening sdbus (like with operator >> in your example).

This would help at the level of convenient API. Maybe could serve as a step for such extensions on the generated API level (#275)...

Do you have any comments or thoughts from your perspective?

[michab66]

This functionality would be very helpful especially on the generated-API-level. The problem is that there's no clear way how to integrate structure definitions into the current XML without breaking validation constraints. An interesting feature would be a different way of expressing the interface, but based on a stripped down version of OMG IDL or QT's qface. Or sdbus-c++ offers a sbus-c++-specific extended XML-format, that allows to define structures. I would volunteer for a prototype, but the basic decision on which interface-description format to use would be helpful.

[sangelovic]

It's now official that signature_of and Message extraction/insertion operators are part of public API and can be extended by clients for their custom types. See #346, #347, #348.