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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg