Re: dbus protocol change (truncate support)

[Alexander Larsson <alexl redhat com>]

On tis, 2013-10-29 at 05:27 +0200, Ross Lagerwall wrote:
> On Mon, Oct 28, 2013 at 08:44:45PM +0200, Ross Lagerwall wrote:
> > 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.

The old call would not forward to the new dbus call, as like you say you
would then get the wrong kind of response. But it would forward to the
same internal code that backs the new call, then just extract the right
information from the reply to that and marshal back in the old style.

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

Exactly. You just have two handlers for the same job type:

  g_signal_connect (skeleton, "handle-open-for-write", G_CALLBACK
(g_vfs_job_open_for_write_new_handle), data);
+  g_signal_connect (skeleton, "handle-open-for-write-flags", G_CALLBACK
(g_vfs_job_open_for_write_new_handle_with_flags), data);

Then gvfsjobopenforwritte.c:create_reply() would pick the right reply
method based on how it was constructed.

> > 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?
>
> Or a single uint32 representing a bitwise-mask of flags.

This is what i meant.