Bug 20948

Created attachment 24401 [details]
Fprintd device D-Bus interface

Comment on attachment 24401 [details]
Fprintd device D-Bus interface

Please see property scan-type and num-enroll-stages.

I don't see any restrictions on property names in the specification as it stands now.

So the concrete issue here is that these names are not usable in the Qt bindings.  Is there a way we can change the Qt bindings to make them usable?  For example if it also exposed a string-based API for properties like .GetProperty("foo-bar").

I'm wary of trying to add a property name restriction now, precisely because there's already deployed code using these names.  

It may be possible to have the GLib bindings *also* allow retrieving properties using "_" transparently if it doesn't do so already.  Then from Qt you could use _ anywhere - is used (GObject does this too).

(In reply to comment #3)
> I don't see any restrictions on property names in the specification as it
> stands now.

IMHO subpart Member names in:
http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names


> So the concrete issue here is that these names are not usable in the Qt
> bindings.  Is there a way we can change the Qt bindings to make them usable? 
> For example if it also exposed a string-based API for properties like
> .GetProperty("foo-bar").

interface.property("num_enroll_stages")

Qt bindings could change regular expression (add dash to it) for member names.

There is now that code:

if (!QDBusUtil::isValidMemberName(methodName)) {
    qWarning("Invalid D-BUS member name '%s' found in interface '%s' while parsing introspection",
    qPrintable(methodName), qPrintable(ifaceName));
    continue;
}

Where isValidMemberName is
{
    if (memberName.isEmpty() || memberName.length() > DBUS_MAXIMUM_NAME_LENGTH)
        return false;

    QRegExp regex(QLatin1String("[a-zA-Z_][a-zA-Z0-9_]*"));
    return regex.exactMatch(memberName);
}

So I getting this error:
Invalid D-BUS member name 'scan-type' found in interface 'net.reactivated.Fprint.Device' while parsing introspection
Invalid D-BUS member name 'num-enroll-stages' found in interface 'net.reactivated.Fprint.Device' while parsing introspection



> 
> I'm wary of trying to add a property name restriction now, precisely because
> there's already deployed code using these names.  
> 
> It may be possible to have the GLib bindings *also* allow retrieving properties
> using "_" transparently if it doesn't do so already.  Then from Qt you could
> use _ anywhere - is used (GObject does this too).
> 

This will be great, but it doesnt work now.

"Member" refers to a specific DBus concept (the last component part of a message, used in the wire protocol), whereas properties come across as strings (i.e. any UTF-8).

It would probably be reasonable to restrict property names to some UTF-8 subset, but the specification does not do that now.

I believe my reading of the D-Bus spec is correct: member names (signals, properties and methods) cannot have dashes. The names are traditional C identifiers: they start with a letter and may contain digits and the underscore.

In fact, each component of an interface name or error name is a C identifier: this matches Java, which is where the reverse-domain notation came from. The only exception is bus names, which allow the hyphen (those are allowed in DNS, where the underscore isn't allowed).

So, no, I will not change Qt implementation to accept them. I will remove the warning and just make the property be ignored. My suggestion is that the glib binding list both properties in the XML, or just the underscore-based property.

If you need to access non-compliant names, you can use the Get, Set and GetAll calls in the org.freedesktop.DBus.Properties interface directly.

The specification is very focused on the wire protocol, and here "member" has a very specific meaning and it does not include properties.  Look at the header table:

MEMBER	3	STRING	METHOD_CALL, SIGNAL	The member, either the method name or signal name.

That's what member means.  It does not mean "something like an identifier". 
The rest of DBus names are equally well defined, like "interface name" has an explicit definition under "Interface names".

Properties are not mentioned here, because they're not part of the wire protocol.

How exactly various DBus names and concepts map to *language* methods, signals, and properties is up to the language+binding.  It's certainly conceivable that a language would disallow e.g. '_' as an identifier character, and that would be up to the binding to deal with.

Anyways, I definitely want to find a practical solution here.  I don't think we can create that property name restriction now, because too much deployed code already uses properties with those names.

If the Qt restriction can't be lifted in any way, then I guess the recommended workaround for this issue will be to use the .Get method directly.  It's worth documenting.

Unfortunately, I cannot lift the limitation. Even if I created meta objects with properties with dashes or other characters, there would still be problems in generating C++ compileable code to get and set properties. QtDBus does not do any transformation of method, signal or property names: they map 1:1 to the C++ identifier.

For that reason, there's also no way of making a QtDBus-based application provide a property whose name contains a dash.

I understand that the spec doesn't specifically mention property names. But I stand by my reading, especially in light of the fact that signals, methods and properties are treated at the same level in the XML introspection. I believe that, while not mentioned, this was intended.

I will remove the warning and document this interoperability issue.

(In reply to comment #6)
> So, no, I will not change Qt implementation to accept them. I will remove the
> warning and just make the property be ignored. My suggestion is that the glib
> binding list both properties in the XML, or just the underscore-based property.

The warning is good for me. Thanks to it I have idea where is problem. Warning message is better than quietly ignoring wrong names.

> 
> If you need to access non-compliant names, you can use the Get, Set and GetAll
> calls in the org.freedesktop.DBus.Properties interface directly.
> 

Pretty hard way to get one string and one integer, but I think there is no other way in that time.

Yeah, unfortunately the XML introspection doesn't even have a schema/DTD.  Don't get me wrong - if we could make the spec explicitly restrict this I'd be in favor, but backwards compatibility is an issue.

Also, from my quick reading of the dbus-glib code, it looks to me like it should accept '_' in place of '-' for property names (because g_object_class_find_property eventually does this) on the wire.

> 
> Also, from my quick reading of the dbus-glib code, it looks to me like it
> should accept '_' in place of '-' for property names (because
> g_object_class_find_property eventually does this) on the wire.
> 

Maybe I am dumb, but how can I profit from it in Qt application?

I remember researching DTD once and concluded that it just wasn't possible. And I don't think we can validate with XSD either, unless we make it really big.

I don't remember what the exact issue with DTD was, but I remember it was caused by its inflexibility. As for XSD, the problem is validating the D-Bus signatures in type="...".

Ok,

I changed my application to use org.freedesktop.DBus.Properties and it works now.

Thank you

But access to properties with dash in name will need some changes ;-).

dbus-glib is deprecated, and we know it has design flaws that cannot be fixed for backwards compatibility. This is not going to be fixed, sorry.

I recommend using GDBus or QtDBus in new code, and not conflating D-Bus property names with GObject property names like dbus-glib did.