DBus API problems & UTF-8

Thiago Macieira thiago.macieira at trolltech.com
Mon Jun 12 02:06:34 PDT 2006


Kimmo Hämäläinen wrote:
>For example, if dbus_message_iter_append_basic() returns FALSE, the
>caller cannot know whether 1) an invalid argument was provided, or 2)
>out-of-memory happened. However, the caller might want to handle
>situation 1 differently from 2.
[snip]
>Is there any will to fix these API problems? I propose fixing them by
>providing additional API that would be as close to the old as possible
>and slowly deprecating the old API.

The solution would probably be to have a DBusError that is attached to 
that message and is set by any failing functions. This way, there would 
be no API changes, but it would allow you to obtain the error condition.

It would require, internally, that the validation checks 
(_dbus_return_if_val and similar functions) be changed to take an error 
condition as well.

>Btw. why on earth DBus has to limit valid string data to UTF-8? I see no
>reason why the string data should be even validated in the server (as it
>now does). Seems like another unnecessary limitation -- or perhaps a
>some kind of political statement (think of some very widely used Asian
>encodings).

Because we don't want to hear about encodings. If you do that, then client 
and server have to negotiate an encoding before they can start receiving 
strings from one another. There's also the potential that one of the two 
doesn't have the necessary codec installed.

So we avoid the problem by saying that all strings are Unicode (just like 
in Java and Qt). The wire format just says that the encoding is UTF-8 for 
strings. Internally, the applications can use whatever encoding they 
prefer (in Qt, we expand to UTF-16 before passing to the user).

If you need to send something in another encoding, send as ARRAY of BYTE, 
with the encoding identification (e.g., the MIB) as a separate parameter.
-- 
Thiago José Macieira - thiago.macieira AT trolltech.com
Trolltech AS - Sandakerveien 116, NO-0402 Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060612/7e26e8ed/attachment.pgp


More information about the dbus mailing list