On September 8, 2009, Colin Walters wrote: > On Mon, Sep 7, 2009 at 10:53 PM, Aaron J. Seigo<[email protected]> wrote: > > 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? > > https://bugs.freedesktop.org/show_bug.cgi?id=20948 > > has my comments on the issue. I will say though if someone made a > patch for dbus-glib which made it optionally export properties in the > suggested way (say keyed off an XML flag) I'd happily accept. I'd > also suggest new dbus bindings do this by default. > > But changing the spec is wrong, unless you also have a time machine.
it's not wrong, it's just harder than doing nothing and hoping nobody else stubs their toe on this. which they just did. and i'm sure they will again. and what's the answer in this specific case? change the property names in that interface so they work. in other words, we have "the spec" and we have "the reality". Thiago's comments in that bug report spell it out pretty clearly the reasons for the reality as we have it. now, you say that we can't change the spec because we have usage of the current spec (the "also have a time machine" comment). it seems that if we could roll back time and do it properly, we'd have the same character set limitations on properties as we do the other members. can we work towards that? assuming we'd like to make things as good as possible (but only as good as possible) would this be ok as a solution to you: * in the spec, note that properties SHOULD follow the same character set limitations * in the spec, note that some existing implementations will accept other characters but this should can not, in practice, be relied upon * deprecate use of characters outside that character set, and put a sunset date on its usage (some years out) -- 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
