Object Path Naming Conventions

[S.Çağlar Onur]

Hi;

16 Oca 2008 Çar tarihinde, Simon McVittie şunları yazmıştı: 
> On Wed, 16 Jan 2008 at 10:26:06 +0200, S.Çağlar Onur wrote:
> > So could you please tell why this restriction exists, i cannot find any
> > related discussion on mailing list archives and spec. says nothing more?
>
> Why it exists is by now pretty irrelevant - it's important for
> interoperability that all D-Bus implementations agree on what is a valid
> object path, so the definition of object-path is fixed from now until
> the next incompatible protocol change (ideally, that means forever).

I got it.

> (I wasn't around when D-Bus was designed, but the character set
> restrictions for object paths, bus names etc. all resemble the allowed
> characters in C identifiers; I assume this was to make it easier to map
> them into identifiers in C and similar languages. The only two sane
> choices would seem to be "heavily restricted" (like C identifiers) and
> "completely arbitrary" (like Unix filenames), and the designers of D-Bus
> chose the "heavily restricted" option.

Fair enough.

> I suggest using some suitable reversible escaping mechanism; if your
> package names are almost, but not quite, valid object path components,
> you could copy tp_escape_as_identifier() from telepathy-glib (it's
> basically URI escaping, with _ instead of % and a smaller allowed
> character set, and it produces names which are valid object path
> components, bus name components and C identifiers).

Currently basic substitution works (change any non valid char into "_") for 
us :), i just wanted to know why are they restricted and possibility of 
extending this but, as you said, from interoperability point of view this is 
something not prefered.

> Latest version of tp_escape_as_identifer(): search for it in
> http://darcs.collabora.co.uk/darcsweb.cgi?r=telepathy/telepathy-glib;a=head
>blob;f=/telepathy-glib/util.c, or check out
> http://darcs.collabora.co.uk/darcs/telepathy/telepathy-glib with Darcs and
> look in telepathy-glib/util.c.
>
> There is no tp_unescape_identifier() (we've never needed it - we only
> use a reversible algorithm to guarantee that distinct strings
> will produce distinct object paths) but it would be entirely possible to
> implement it.
>
> There's a Python implementation of the same algorithm in the OLPC's
> Presence Service
> (http://dev.laptop.org/git?p=projects/presence-service;a=blob;f=src/psutils
>.py;hb=HEAD, search for escape_identifier).

Thanks for the pointers.

>     Simon

Cheers
-- 
S.Çağlar Onur <caglar at pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080116/0e476229/attachment.pgp