Exposing some type details in the introspection XML?

[Marc-André Lureau]

Hi

On Fri, May 15, 2020 at 6:48 PM Simon McVittie <smcv at collabora.com> wrote:

> On Fri, 15 May 2020 at 15:43:19 +0200, Lennart Poettering wrote:
> > On Fr, 15.05.20 14:01, Simon McVittie (smcv at collabora.com) wrote:
>
...

> > That all said, maybe if there's somebody who wants to work on this:
> > maybe XML is a shitty choice for introspectionin 2020.
>
> It's certainly not the easiest language to write in. When I used to work
> on Telepathy, I often found myself writing design proposals in an informal
> pseudo-IDL:
>
>     interface o.fd.Telepathy.Pokable:
>       method Poke(b: with_stick, a{sv}: properties) -> as: ouch
>         Poke the object, possibly with a stick. Return the noises it makes.
>
>         with_stick: If true, maintain social distancing.
>         properties: Every time we don't add an a{sv} we regret it later.
>
> and wishing I could generate the code from a more formal version of that,
> rather than from something as verbose and human-author-unfriendly as XML.
>
> The IDL in
> https://blogs.gnome.org/alexl/2020/01/14/introducing-gvariant-schemas/ is
> relevant to this topic, although that only describes data types, not entire
> D-Bus interfaces.
>
> > And I mean:
> > a(sa(sa(sa(sgya{sv})a{sv})a(sa(sga{sv})a{sv})a(sgya{sv})a{sv})a{sv}) ←
> > that's just so delicious! Just think about how much more awesome this
> > signature string could be if there were structures.
>
> Somewhere, something went horribly wrong...
>

Feels like quite an intimidating task to define a new IDL for DBus. And I
am not convinced the various bindings / code generators will follow,
because parsing it will be an additional pain, whereas XML, well, it's
there and it's easy to add new attributes/elements for existing code &
interfaces. Perhaps the "delicious" giant a{sv} is indeed a better
proposal, since it fits nicely. But to me it's just a dbus marshalled
version of the XML, and we are back to similar problems/considerations
regarding the schema. It may be even less convenient, less flexible, beside
being humanly unreadable, and pretty shallow.

In the past (commit f3549401113b "spec: Allow <annotation> in <arg>
elements in introspection XML", or commit dc12fac5f8a36d), we have modified
the introspection schema slightly, without bumping version etc. Did it
bother anyone? Can we further add elements or attributes here and there,
without touching the existing ones?

Although I can't find it explicitly in the spec, I suppose the
introspection XML is free to introduce extra/new xml namespaces already in
a compatible manner, correct?

Clearly, it would be inconvenient if both client & servers would have to
handle different introspection formats/versions in the future.

thanks



-- 
Marc-André Lureau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20200708/9a1bfaf8/attachment.htm>