Object path restrictions

[Pavel Strashkin]

2011/6/17 Simon McVittie <simon.mcvittie at collabora.co.uk>:
> Because the specification says so, and it's about 5 years too late for
> non-interoperable changes. I have no idea what the original reasoning was,
> but at this point it doesn't really matter; we're not going to break all
> implementations and bindings.

The extending (minor!) doesn't mean the breaking. I didn't say "rename
A to B" or "change / to ^" as delimiter.
I just said let's allow to use not only "[A-Z][a-z][0-9]_", but other
valid ASCII characters for object
path elements and (may be, may be) introduce the escaping. It breaks
nothing. If you haven't used it
before - everything still works, but you also allow to developers be
more flexible (and make code more clean)
without this "tp_escape_as_identifier" hacks which are provided only
by telepathy-glib. What about Perl? Python?

> telepathy-glib has tp_escape_as_identifier() which uses _XX for URL-style
> quoting, producing strings which are valid in all D-Bus contexts (bus name
> component, object path component, interface component, member) and also in
> C/C++ identifiers. I suggest using a similar algorithm to encode arbitrary
> strings into object paths; if a component gets too long you might have to
> resort to hashing the initial string and writing it in hex, though.

I'll take a look on it, but i'm still very confused why do you believe
that the feature is provided by tp_escape_as_identifier cannot be the
part of D-Bus, especially when it doesn't break anything, just
extending and improving. I have C/Perl/Python services/clients - i
don't want to backport tp_escape_as_identifier everywhere and remember
about it, i just want to use D-Bus and be sure that "192.168.0.1" is
allowed object path element.