DBus API problems & UTF-8

[Rob Taylor]

Kimmo Hämäläinen wrote:
> On Mon, 2006-06-12 at 13:09, ext Ross Burton wrote:
>> On Mon, 2006-06-12 at 12:40 +0300, Kimmo Hämäläinen wrote:
>>> I mean DBUS_TYPE_STRING. I think the specification should just say
>>> that
>>> it's a NUL-terminated sequence of bytes. That way we don't have to
>>> care
>>> about encodings, and we don't have to verify UTF-8 in the server
>>> (there
>>> is already enough unnecessary O(n) stuff happening in the code...).
>>>
>>> My point is that the DBus specification does not seem to have any
>>> reason
>>> for specifying UTF-8 as the encoding -- NUL-terminated byte (save zero
>>> byte) array would allow for more efficient communication when some
>>> other
>>> encoding is used between applications, and the validity check for the
>>> string data would be left entirely to the applications (where it
>>> belongs
>>> -- DBus is just a message bus, it should not inspect the content). 
>> So if my GTK+ application wants to communicate with a Qt application, I
>> need to know that the Qt applications are talking in UTF-16 and convert
>> my strings?
>>
>> If a Qt application wants to send a message to the message bus itself it
>> has to change the strings to UTF-8 (assuming the bus itself remains
>> speaking UTF-8).
> 
> You can still have contract between the applications to use UTF-8
> encoding in that case. I'm not sure if DBus should police that. If we
> want policing, we could have a new type DBUS_TYPE_STRING_UTF8.
> 
>> Making the validation optional would speed performance, but I don't
>> fancy having to introspect every client my application talks to just to
>> find out what encoding they are using, hoping I have access to a codec
>> for it, and then transforming all of my strings.
> 
> Yes, I'm sure Gtk application developers like it, but sometimes UTF-8
> does not make much sense. Sometimes they just want to pass C strings
> around conveniently.
> 

Then use ay.

Thanks,
Rob Taylor