[Interest] Beginner DBUS Question: how to enforce the XML?

[Thiago Macieira]

On Wednesday, 16 June 2021 07:20:31 PDT Jason H wrote:
> > If they aren't used, why do you care? It's the same as requiring everyone
> > to use blue pens: if it's not part of something you see, why do you care?
> Well it's more about not trusting the competence of the other side. Or,
> alternatively, them not trusting a n00b (me). Perhaps I waxed too
> philosophical. Yeah, it would be possible to use an alternative function,
> which should be caught in code review, but I'm looking for something
> brain-dead simple and preferably enforceable by the CI system.

Maybe you need to explain what the actual issue is.

It *looks* like your concern is that you may have updated the API on one side, 
but the other hasn't. Let's say, for example, that you had:

  GetData(in What: s, out Result: a{sv})

which is what your client code does, as in:

  QDBusReply<QVariantMap> result = iface.GetData(dataname);

But now you've updated the server side, so the API is now:

  GetData(in Section: s, in What: s, in Options: a{sv}, out Result: a{sv})

What happens in this case?

When the client code attempts to be recompiled, if the "iface" object is 
generated every time from XML, you'll get a compilation error because of the 
parameter count difference.

If the client hasn't been recompiled, there'll be no error when starting it. 
It will send a method call message with a single argument of type "s" 
(string). Then it's up to the receiver to decide how to handle that message: 
if it's QtDBus, it won't find a slot that matches the incoming arguments and 
will reply with a D-Bus error message. The QDBusReply object in the client 
will contain that error.

So this is no different than API versioning. If you're going to modify your 
API, you need to either have a flag day where everyone stops using the old 
one, or you need to keep compatibility with the old API for a time. Or both. 
This also limits what changes you can make.

The reverse (older server, newer client) is also possible. In that case, the 
client may want to send the newest call first and handle the error condition 
of the called function not being present, then downgrading to the older API. 
Alternatively, you can add a function that returns the API level or version.

Some bindings (QtDBus included) do allow function overloading, so you can have 
two functions called GetData, with different parameters. This is allowed in 
the D-Bus specification, but discouraged because some other bindings may not 
handle the situation. If you use those, that was your choice. In that case, 
you may need to add a new function, with a different name, to support the new 
API.

Another solution is to add interfaces to the receiver object or to add more 
objects with the new API.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering