Email with Alexander Larsson at Redhat:

> >  For instance, in gvfs when i want to "mount" a share I have to construct
> >  a smb://server/share/ uri and then stat that. If the stat succeeded I
> >  assume there is an outstanding connection to the share availible. If we
> >  get an EACCESS or other error we assume the mount failed.
>
> If you could have exactly the functionality and interface you desired
> in libsmbclient to solve this particular issue, what would it be?

I'm not really an expert in the lowlevel details of smb, so I can't say
exactly what the best API would be, but I can try to describe from a
highlevel point of view.

First of all, I'm not interested at all in the uri stuff. Especially the
weirdness of the smb: protocol wrt networ, workgroup and server
enumeration. Instead I'd like first class objects and method that map to
whats actually happening. I.e. a separate API to query for workgroups,
servers and shares that is not readdir() based.

Then I'd like the API to be explicitly stateful, meaning that in order
to access a server/share I have to create some kind of session object
and connect that to the server. Then I want to be able to send requests
to this session (based on share relative paths, not uri stuff). I also
want certain details to be exposed on the session object, like what
filename encoding the remote side has and whatever other details were
negotiated. And also information about the remote side version and
implementation if availible (so I could e.g. whitelist or blacklist
specific implementations).

Another important aspect is multiple outstanding requests, see below.

> >  I would like an API that is specific to smb, and exposes more the
> >  details of SMB. So, you'd have maybe an object for a session with a
> >  share, and an operation to connect to a share that returns said object.
>
> That's similar to the nt_create function mentioned previously.

Not sure exactly what this function would do.

> >  I'd also like the possibility to have multiple outstanding operations on
> >  a connection (is that possible with smb? i assume so). This could be
> >  done using threads and blocking calls, or using an asynchronous form of
> >  libsmbclient i/o calls.
>
> There's been other discussion of a plugable event system, which would
> also allow for the _possibility_ of async calls.  That won't be a
> trivial piece of work in any case, but it could be possible in the
> future.

They don't *have* to be async, but I need some way of having multiple
outstanding requests. Let me explain where this comes from. Gvfs is a
virtual filesystem in userspace, it lets you easily browse for and
access things like smb shares and ftp servers as a user (no need for
root access or admin setup).

Each "backend" is implemented as a daemon process that handles a
"mount", such as a connection to an smb share. All the processes in the
users desktop session talk to this daemon in order to do I/O on the
share. Now, with libsmb the daemon can only have one outstanding
operation, because libsmbclient is synchronous and not threadsafe. If
multiple processes do i/o on the share, or if a process does several
parallel async i/o request (which e.g. nautilus will do) then these will
all be serialized. And what is worse, they will be serialized on the
client side, meaning the latency from sending packets to the server is
added to the time waiting for the currently active operation.

The solution to this is either:
Allow multiple threads to call into libsmbclient so that each operation
can block and yet allow multiple outstanding requests.
Allow async calls so we can just emit the requests, and then handle the
request responses as they come back.

I undestand these are probably both very hard to do with the
libsmbclient codebase, but you asked for the ideal libsmbclient.