sdbusplus updates (client-bindings and namespace)

[Lei Yu]

On Mon, May 8, 2023 at 4:38 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Fri, May 05, 2023 at 05:09:53PM +0800, Lei Yu wrote:
> > On Thu, May 4, 2023 at 6:23 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> > >     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
> >
> > The previous class was using `Object` but now with the new namespace
> > it becomes `object`, is it intended about the upper-case `O` becoming
> > the lower-case `o`?
> > If yes, why the `Enable` still kept the upper-case `E`?
> > Do we have a rule that all the strings other than the last part should
> > be lower-case?
>
> Yes, this was intentional.
>
> The older namespace code did not apply an explicit style to the
> namespace or server but just used the portions of the interface name.
> We happen to name interfaces in UpperCamelCase.  With the `server` near
> the end, there was no name-identifier collision between:
>
>     * ...Foo -> ...::server::Foo
>     * ...Foo.Create -> ...::Foo::server::Create
>
> By putting the `server` near the beginning you end up with:
>
>     * ...Foo -> server::...::Foo
>     * ...Foo.Create -> server::...::Foo::Create
>

It's noticed that the `error.hpp` is kept and still uses the namespace like
`sdbusplus::xyz::openbmc_project::State::Host::Error::BMCNotReady`, instead of
`sdbusplus::error::xyz::openbmc_project::state::host::BMCNotReady`.

Should we change the error namespace as well to keep consistency?

-- 
BRs,
Lei YU