Re-unifying udisks and storaged

[Simon McVittie]

On Fri, 02 Dec 2016 at 15:23:19 +0100, Vratislav Podzimek wrote:
> (e.g. byte arrays instead of strings, everything synchronous,...)

There is probably a reason for these design decisions. Think carefully
before breaking them.

Byte arrays on D-Bus, in places where you expect a string, usually mean
that someone thought about it carefully and realised that there is
nothing that guarantees that the content will be UTF-8, or even Unicode
in any known encoding. This usually happens with POSIX filenames and/or
environment variables.

D-Bus strings are *always* UTF-8, with no "\0", no overlong sequences,
no non-Unicode codepoints (above U+10FFFF) and so on. POSIX filenames
have no such guarantee: I can do creat("/home/smcv/\xff", 0644)
(which is not valid UTF-8, just some byte sequence) and system tools
will just have to deal with it.

Meanwhile, a D-Bus method that doesn't return until it has had its effect
doesn't mean the client has to block on it, and also doesn't mean the
service has to block while it is processing that method - it can be async
at both ends. D-Bus is just message-passing: a method call is just
syntactic sugar for a method call message, and after some time passes,
a reply message going back the other way.

There are sometimes good reasons to want to create "transaction" objects,
for example being able to inform multiple clients about the status of the
same operation, or being able to make the operation cancellable. If those
reasons apply (which I can well imagine they do in udisks/storaged)
then you should consider adding transaction objects. However,
only add that complexity to your API if those reasons do apply - don't
create transaction objects just because you don't want to block, because
you don't have to block anyway.

    S