<div dir="ltr"><div dir="ltr">Hi<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 8, 2020 at 12:11 AM Marc-André Lureau <<a href="mailto:marcandre.lureau@gmail.com">marcandre.lureau@gmail.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"><div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > 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><br></div></div></blockquote><div><br></div><div>So I toyed with this idea a bit in zbus, and would like to get some feedback before I go further. Eventually, I can either try to implement the proposal in sd-bus or gdbus. I would like to invite the maintainers of go and python bindings to give feedback, and eventually give a try at implementing it, if they are interested.</div><div><br></div><div>As we can't extend the current XML without risk of breaking parsers, and we would have to open the door to other formats eventually (custom binding formats too, perhaps), let's start with a new Introspect() method:</div><div><br></div><div> <interface name="org.freedesktop.DBus.Introspectable2"><br> <method name="Introspect"><br> <arg name="format" type="s" direction="in"/><br> <arg name="options" type="a{sv}" direction="in"/><br> <arg type="ay" direction="out"/><br> </method><br> </interface><br></div><div><br></div><div>That should be straightforward, a new interface Introspectable2 is added, with a new method to introspect, that takes a format as a string (for example "dbus.v1"), our idiomatic "a{sv}" dict for options (I think we could have common options, such as "dbus.depth", "dbus.only-nodes" etc, and format specific options with for example "fmt.comments").</div><div><br></div><div>The returned value is changed to "ay", so it can return anything (although most likely utf8 strings).<br></div><div><br></div><div>I would like to extend the current XML, let's call it "dbus.v2" format for example for the above method, or v2 in short. The goal is that a v2 parser should be compatible with current v1 XML documents. It should also be fairly easy to extend a v1 parser to support v2. Or to generate v2 progressively from v1. In other words, I tried to extend the v1 format in some compatible manners, so both v1 and v2 can coexist and share code.<br></div><div><br></div><div>- Comments</div><div><br></div><div>I propose to have  comments to be associated with the next element. Ex:<br></div><div><br></div><div> <br> <interface name="org.freedesktop.PolicyKit1.Authority"</div><div><br></div><div>We could standardize on the markdown syntax too.</div><div><br></div><div>- New elements</div><div><br></div><div>Since a well-formed XML document should have only one top-level element, I propose to allow various new type elements to the top-level <node/>. Alternatively, we could have a new <introspect> root element, and have a single child <node> there.<br></div><div><br></div><div>- New type names<br></div><div><br></div><div>Some proposed elements introduce new type names. I propose to change a bit the way the "type" attributes are usually parsed and interpreted. If the type starts with a capital, then the alphanumeric characters that follow form a type name (that references a type element). Additionally, "[T]" is added for array types. No dictionary syntax is necessary. Complex types can be represented with <structure> types.<br></div><div><br></div><div>- <error> element<br></div><div><br></div><div>This element declares an error domain. It must have a domain name, and a type, and list the various errors as childrens. Ex:<br></div><div><br></div><div> <br> <error domain="org.freedesktop.PolicyKit1.Error" type="s"><br> <item name="Failed"/><br> <item name="Cancelled"/><br> <item name="NotSupported"/><br> <item name="NotAuthorized"/><br> <item name="CancellationIdNotUnique"/><br> </error><br></div><div><br></div><div>the <interface> gains a new attribute error="org.freedesktop.PolicyKit1.Error" to associate the interface methods with the error domain.</div><div><br></div><div>- <enum> type element<br></div><div><br></div><div>Declares an enumeration. It must have a name and a basic type attribute. Each item has an optional name and a value. (the name is optional, it can be generated by the binding, and we can have enum of strings without repeating name/value), ex:<br></div><div><br></div><div> <br> <enum name="ImplicitAuthorization" type="u"><br> <item name="NotAuthorized" value="0"/><br> <item name="AuthenticationRequired" value="1"/><br> <item name="AdministratorAuthenticationRequired" value="2"/><br> <item name="AuthenticationRequiredRetained" value="3"/><br> <item name="AdministratorAuthenticationRequiredRetained" value="4"/><br> <item name="Authorized" value="5"/><br> </enum></div><div><br></div><div> <br> <enum name="SubjectKind" type="s"><br> <item value="unix-process"/><br> <item value="unix-session"/><br> <item value="system-bus-name"/><br> </enum></div><div><br></div><div>- <dictenum> type element</div><div><br></div><div>Declares a dictionary, by listing the well-known keys (and if the set of accepted keys is strict), and associated types. If the key type is "v", the items should have an associated type too.<br></div><div><br></div><div>Ex:</div><div><br></div><div> <br></div><div> <dictenum name="PersonDetails" type="ss"><br> <item value="firstname"/><br> <item value="lastname"/><br> </dictenum><br></div><div><br></div><div> <br> <dictenum name="IdentityDetails" type="sv"><br> <item value="uid" type="u"/><br> <item value="gid" type="u"/><br> </dictenum><br></div><div><br></div><div>- <struct> type element</div><div><br></div><div>Declares a struct, with field name and type. Ex:<br></div><div><br></div><div> <br></div><div> <struct name="TemporaryAuthorization"><br> <item name="id" type="s"/><br> <item name="action_id" type="s"/><br> <item name="subject" type="Subject"/><br> <item name="time_obtained" type="t"/><br> <item name="time_expires" type="t"/><br> </struct><br></div><div><br></div><div>With the above, it becomes possible to generate much nicer high-level bindings. With zbus, we go from v1 <a href="https://gitlab.freedesktop.org/snippets/1117">https://gitlab.freedesktop.org/snippets/1117</a> to <a href="https://gitlab.freedesktop.org/snippets/1118">https://gitlab.freedesktop.org/snippets/1118</a> (the v2 XML: <a href="https://gitlab.freedesktop.org/snippets/1119">https://gitlab.freedesktop.org/snippets/1119</a>).</div><div><br></div><div>What do you think?<br></div><div><br></div><div>thanks<br></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">Marc-André Lureau<br></div></div>