sdbusplus updates (client-bindings and namespace)

[Patrick Williams]

Greetings,

TL;DR: I have two announcements of changes in sdbusplus:

    1. Async client bindings using C++20 coroutines are now available
       for experimentation.
    2. The namespace for server bindings has changed, but the old
       namespace is preserved for a period of ~6 months.

----

As part of developing the async client bindings, I fixed a mistake I
made in 2016, which was choosing a terrible convention for the
namespaces of the generated server bindings:

    Interface: xyz.openbmc_project.Object.Enable
    Old Class: sdbusplus::xyz::openbmc_project::Object::server::Enable
    New Class: sdbusplus::server::xyz::openbmc_project::object::Enable
    Client Class: sdbusplus::client::xyz::openbmc_project::object::Enable

There is a type alias, enabled by default, which provides backwards
compatibility for old code.  I will leave this in place for
approximately 6 months.  In order to test compiling your code without
this alias you can `-DSDBUSPP_REMOVE_DEPRECATED_NAMESPACE`.

I have developed a client-binding using C++20 co-routines.  I've
previously mentioned the implementation of the underlying support in 
sdbusplus for co-routines[1,2] using the C++26 proposed "P2300
std::execution" implementation[3] but now `sdbus++` will generate a
`client.hpp` for any interface-YAML.  This is already hooked up in
phosphor-dbus-interfaces and ready for experimentation.

Some interesting code:
    - An example client application[4] to go with the example server[5].
    - The generated client.hpp[6] for `net.poettering.Calculator`[7].
    - A class[8] to combine multiple client-proxies into a single instance,
      which is the client analog of `sdbusplus::server::object_t`.

Next steps:

    - Probably some bug fixes as other eyes start using this.

    - Implement something like `async-server.hpp` to create async server
      bindings to go along with the clients, which will allow a fully
      async daemon without Boost (and with a lot cleaner code than ASIO
      callbacks).

    - Add the opposite of `throw
      sdbusplus::xyz::openbmc_project::Common::Error::NotAllowed()` in
      the client bindings to turn an exception on the server side back
      into an identical exception on the client.

    - Add some kind of functions in the client bindings that generate
      `sdbusplus::async::match` instances for `co_await` on a signal.

    - Figure out a migration path for Boost ASIO such that
      `sdbusplus::asio::connection` holds an `sdbusplus::async::context`
      and code can be piecemeal refactored to C++ co-routines.

As always, please reach out if you have questions or run into trouble!

[1]: https://lore.kernel.org/openbmc/YaPzMYi%2FUHwvEiGf@heinlein/
[2]: https://lore.kernel.org/openbmc/Y9fgEdigX0aTiM0d@heinlein.taila677.ts.net/
[3]: https://github.com/NVIDIA/stdexec
[4]: https://github.com/openbmc/sdbusplus/blob/master/example/calculator-client.cpp
[5]: https://github.com/openbmc/sdbusplus/blob/master/example/calculator-server.cpp
[6]: https://gist.github.com/williamspatrick/a4ffa6bc9154d5fe460d46c1654c04bf
[7]: https://github.com/openbmc/sdbusplus/blob/master/example/yaml/net/poettering/Calculator.interface.yaml
[8]: https://github.com/openbmc/sdbusplus/blob/master/include/sdbusplus/async/client.hpp

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230503/2e82b0d3/attachment.sig>