Bug 20948

Summary: GObject property names vs D-Bus property names
Product: dbus Reporter: Jaroslav Barton <djaara>
Component: GLibAssignee: Rob Taylor <rob.taylor>
Status: RESOLVED WONTFIX QA Contact: John (J5) Palmieri <johnp>
Severity: normal    
Priority: medium CC: bugzilla, djaara, jreznik, thiago, walters
Version: 1.2.x   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Fprintd device D-Bus interface

Description Jaroslav Barton 2009-03-30 08:29:18 UTC
Hi all,

I am developing KDE/Qt application for managing enrolled fingerprints. This application uses fprintd d-bus daemon (http://reactivated.net/fprint/wiki/Fprintd).

Fprintd is GObject/Glib based application. GObjects expect dashes in property
names, so this should be fixed in dbus-glib instead (http://lists.reactivated.net/pipermail/fprint/2009-March/001139.html).

Fprintd exports some properties with dashes in their names and my Qt based application cannot access this properties. Qt has strict property names restriction described this retular expression: [a-zA-Z_][a-zA-Z0-9_]* . This regular expression is compliant with standard.

I got only 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

Is there any way to translate Glib property names to D-Bus property names (dashes to underscores) and backwards?
Comment 1 Jaroslav Barton 2009-03-31 07:33:17 UTC
Created attachment 24401 [details]
Fprintd device D-Bus interface
Comment 2 Jaroslav Barton 2009-03-31 07:34:25 UTC
Comment on attachment 24401 [details]
Fprintd device D-Bus interface

Please see property scan-type and num-enroll-stages.
Comment 3 Colin Walters 2009-03-31 08:49:13 UTC
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).
Comment 4 Jaroslav Barton 2009-03-31 09:32:48 UTC
(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.

Comment 5 Colin Walters 2009-03-31 09:39:46 UTC
"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.
Comment 6 Thiago Macieira 2009-03-31 09:45:08 UTC
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.
Comment 7 Colin Walters 2009-03-31 10:00:15 UTC
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.
Comment 8 Thiago Macieira 2009-03-31 10:21:38 UTC
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.
Comment 9 Jaroslav Barton 2009-03-31 10:22:24 UTC
(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.
Comment 10 Colin Walters 2009-03-31 10:37:06 UTC
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.
Comment 11 Jaroslav Barton 2009-03-31 10:54:42 UTC
> 
> 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?
Comment 12 Thiago Macieira 2009-03-31 11:04:44 UTC
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="...".
Comment 13 Jaroslav Barton 2009-03-31 13:19:15 UTC
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 ;-).
Comment 14 Simon McVittie 2014-09-16 12:55:42 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.