Versioning interfaces
John (J5) Palmieri
johnp at redhat.com
Mon Oct 24 10:35:05 PDT 2005
As long as the version checks are done by the client and not the bus I
am fine with this. Also the use of major/minor should be application
dependent with the rules being outlined bellow being a recommendation.
Should we create a version type that validates the version numbers? If
we did python could easily change 10.2 to (10,2) for easy comparison.
Robert can you make a spec patch that outlines these fields and their
format in the introspection interface section? Come to think of it a
type is not needed, just add to the spec if versions are not in the
sect := [0-9]+
version := (sect.sect(.sect)*)
(something like that) form clients can ignore it.
On Mon, 2005-10-24 at 16:39 +0100, Robert McQueen wrote:
> Something we discussed at the D-Bus BOF at the GNOME summit was
> including some kind of optional interface versioning in the
> introspection data.
>
> My suggestion was be something like an optional version="x.y" attribute
> on <interface>, <signal> and <method> nodes. For the <interface> node,
> this is composed of a major version x, which must be incremented when
> any signal or method is removed, or arguments/functionality changed, and
> the minor version y which must be incremented when a signal or method is
> added. On the <signal> and <method> nodes, the attribute merely
> documents which interface version the signal or method first appeared
> in. Bindings can use these annotations to work out the overall interface
> version.
>
> The client side code is then as simple as adding a method which you give
> an object, an interface name and the version you're expecting, and it
> looks at the introspection data for you and tells you if the provided
> version is compatible (your_x == their_x, and their_x >= your_x).
>
> Obviously this is all backwards compatible - a client doing a version
> check on a service with no version gets a failure, the addition of
> version information to a service when the client does no version check
> doesn't break anything.
>
> Comments?
>
> Regards,
> Rob
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
--
John (J5) Palmieri <johnp at redhat.com>
More information about the dbus
mailing list