DBus API problems & UTF-8

[Kimmo Hämäläinen]

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.

BR; Kimmo

> 
> Ross