DBus API problems & UTF-8

[Kimmo Hämäläinen]

Hi,

Many of the DBus client library functions return a Boolean return code
even though they may have multiple reasons for a failure.

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.

I hear you saying 'who cares about OOM -- RAM never runs out and we have
swap!'. Yes, this is true when using DBus in desktop/server world, but
why should we limit its (reliable) usage to desktop/server world only.

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.

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).

BR, Kimmo