DBus API problems & UTF-8

[Kimmo Hämäläinen]

On Mon, 2006-06-12 at 16:05, ext Daniel P. Berrange wrote:
> On Mon, Jun 12, 2006 at 03:32:02PM +0300, Kimmo H?m?l?inen wrote:
> > On Mon, 2006-06-12 at 15:47, ext Daniel P. Berrange wrote:
> > ...
> > > If you're not already using UTF-8 in your C program, then its at most one 
> > > single method call to convert. Unless your strings are absolutely enourmous
> > > the performance hit of the conversion shouldn't show up as a large hotspot.
> > > In any case this is a small price to pay for cross-application interoperability. 
> > 
> > Ok, you all have a good point. However, would you oppose an additional
> > DBus type for NUL-terminated strings (e.g. DBUS_TYPE_CSTRING)? There is
> > quite a bunch of existing C code around that could benefit from it.
> 
> The trouble, is when a client talks to a service, it now has to decide
> whether to use C String, or UTF-8 string. So, either every application
> (or the language bindings) would need to be updated support both formats, 
> or you'd end up with a situation where only some apps spport C strings, 
> which wouldn't be good for interoperability. Since there is no compelling
> reason for most apps to support C strings, unfortunately I think we'd
> end up in the latter situation which isn't a very desirable result.

Hmm. I think this problem would only occur if the specification or
contract between the applications is badly-written. For example, it says
'A sends a string to B' instead of using the DBus type name. But even
now it could be unclear whether a byte array or DBUS_TYPE_STRING is
meant.

You will always have similar problems even with the existing types. For
example, some applications could use DBUS_TYPE_INT32 to send Boolean
values and some could use DBUS_TYPE_BOOLEAN for that. These problems are
not solvable in DBus, but in the specifications.

BR, Kimmo

> 
> Regards,
> Dan.