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.
Too late for enhancements for 3.5. Raising version.