<div dir="ltr"><div dir="ltr">Hi<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 15, 2020 at 6:48 PM Simon McVittie <<a href="mailto:smcv@collabora.com">smcv@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 15 May 2020 at 15:43:19 +0200, Lennart Poettering wrote:<br>
> On Fr, 15.05.20 14:01, Simon McVittie (<a href="mailto:smcv@collabora.com" target="_blank">smcv@collabora.com</a>) wrote:<br></blockquote><div>... <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> That all said, maybe if there's somebody who wants to work on this:<br>
> maybe XML is a shitty choice for introspectionin 2020.<br>
<br>
It's certainly not the easiest language to write in. When I used to work<br>
on Telepathy, I often found myself writing design proposals in an informal<br>
pseudo-IDL:<br>
<br>
    interface o.fd.Telepathy.Pokable:<br>
      method Poke(b: with_stick, a{sv}: properties) -> as: ouch<br>
        Poke the object, possibly with a stick. Return the noises it makes.<br>
<br>
        with_stick: If true, maintain social distancing.<br>
        properties: Every time we don't add an a{sv} we regret it later.<br>
<br>
and wishing I could generate the code from a more formal version of that,<br>
rather than from something as verbose and human-author-unfriendly as XML.<br>
<br>
The IDL in<br>
<a href="https://blogs.gnome.org/alexl/2020/01/14/introducing-gvariant-schemas/" rel="noreferrer" target="_blank">https://blogs.gnome.org/alexl/2020/01/14/introducing-gvariant-schemas/</a> is<br>
relevant to this topic, although that only describes data types, not entire<br>
D-Bus interfaces.<br>
<br>
> And I mean:<br>
> a(sa(sa(sa(sgya{sv})a{sv})a(sa(sga{sv})a{sv})a(sgya{sv})a{sv})a{sv}) ←<br>
> that's just so delicious! Just think about how much more awesome this<br>
> signature string could be if there were structures.<br>
<br>
Somewhere, something went horribly wrong...<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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?</div><div><br></div><div>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?<br></div><div><br></div><div>Clearly, it would be inconvenient if both client & servers would have to handle different introspection formats/versions in the future.</div><div><br></div><div>thanks<br></div><div><br></div></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Marc-André Lureau<br></div></div>