DBus properties naming rules

[Aaron J. Seigo]

On September 7, 2009, Matthias Clasen wrote:
> On Mon, 2009-09-07 at 21:02 +0200, Davide Bettio wrote:
> > Hi,
> >
> > I think that dbus specification needs to be updated: naming rules for
> > properties aren't clear.
> >
> > I suggest to apply this simple fix:
> > - Member (i.e. method or signal) names:
> > + Member (i.e. method, signal or property) names:
> 
> Why do you think properties should be treated like members ? This change
> would apply new restriction to property names that have the potential to
> render a lot of existing interfaces noncompliant, for very little gain.

right now we have an inconsistency between one type of item available in an 
interface compared to all the rest. service names, methods, signals all have 
these restrictions on them and properties stand out as odd ducks. consistency 
is a good trait.

from the perspective of creating nice "bindings" to D-Bus services, it's 
really quite nice to be able to take a service and build a class definition or 
an object at runtime with the same names as in the D-Bus service. (and vice 
versa: it's nice to be able to take an object and easily "export" it at 
runtime, verbatim, over D-Bus). properties, with their '-'s and other 
characters that aren't accepted by compilers defeat this practice rather 
handily.

there are implementations out there, such as QtDBus, that stick to these 
restrictions as a general rule rather than apply them to only the parts 
specifically noted as such in the spec.

and this situation has led to us having issues with talking with DeviceKit, 
which publishes properties with '-'s in them.

making the naming schema consistent and uniform naturally seems more correct 
than having randomly different rules for different things and will help avoid 
future problems. as a bonus, perhaps even solve existing ones like DeviceKit 
using '-'s in properties along the way. 

i also don't see the necessity for more character variety in property names 
than in signals, methods or other identifiers in a D-Bus service. what's the 
use case, exactly, beyond preserving existing malformed services?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090907/36971b5d/attachment.pgp