Re: dbus protocol change (truncate support)

[Ross Lagerwall <rosslagerwall gmail com>]

On Mon, Oct 28, 2013 at 05:16:39PM +0100, Alexander Larsson wrote:
> I think the correct solution for this is to ensure that all our dbus
> apis stay stable over time, and any time we need to modify them we do so
> by adding new methods. 

OK, makes sense.

> In this particular case this means we need to support the old
> gvfs_dbus_mount_call_open_for_write() dbus operation, and add a *new*
> one that returns a set of flags rather than several boolean args. Then
> old clients will still work with a simple forwarder to the new call on
> the server side.

I don't have much experience with dbus so I'm wondering exactly how this
would work since if the old call were forwarded to the new call on the
server side, the server still has to respond with the old method
signature.

I could create an OpenForWriteV2 dbus method with the new signature.
The server can then handle both OpenForWrite methods by creating a
GVfsJobOpenForWrite object which then calls either
gvfs_dbus_mount_complete_open_for_write() or
gvfs_dbus_mount_complete_open_for_write_v2() depending on which method
was originally called.

What dbus type were you thinking of when you talk about returning a "set
of flags"?  Perhaps an array or booleans or ints, or a hash table of
something to something?

Regards
-- 
Ross Lagerwall