gvfs and (lib)smbclient (resend)

[Andrew Bartlett]

On Fri, 2014-08-08 at 08:31 -0700, Jeremy Allison wrote:
> On Fri, Aug 08, 2014 at 10:13:40AM +0200, Stef Bon wrote:
> > 2014-08-04 22:42 GMT+02:00 Jeremy Allison <jra at samba.org>:
> > > On Mon, Aug 04, 2014 at 10:31:33PM +0200, Stef Bon wrote:
> > >> Jeremy,
> > >>
> > >> what do you think of being not stable exactly please.
> > >
> > > It's not built or shipped as an external library,
> > > so we change it at will for internal uses (for example
> > > the last big change was when I added all the code to
> > > make cli_XXXX() calls use SMB[2|3] under the covers
> > > so it was available to smbclient.
> > 
> > Does it stay this way? If so, I better do not use it for a fuse fs.
> 
> The problem is the cli_XXX API just isn't complete yet.
> 
> Look at the code being discussed to allow cli_rename()
> to overwrite the target.
> 
> This depends on Win7 (which doesn't seem to implement
> the path-based rename trans2 semantics, only handle
> based - gotta check this myself) and fallback code
> etc. etc.
> 
> We're just not at the stage where we can consider
> cli_XXX an externally supported API yet. We might
> get there, but it's going to take a while as we
> don't know everything we need yet.

Echoing a similar discussion between us and sssd, I wonder where in the
possible boundaries is the most stable API and ABI?

That is, I'm wondering is the backend API in gvfs a stable, public ABI
that we could provide a plugin for?  

I'm just brainstorming, but if
https://git.gnome.org/browse/gvfs/tree/daemon/gvfsbackendsmb.c were part
of Samba, and we had some way to ensure we didn't break it, we might be
able to find a different way out of this conundrum.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba