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
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
