feat(multiclient-support): Provide support for more than one client about webfuse HOT 4 CLOSED

@supermajor , @nosamad: Would you comment the following proposal, please?

Problem

Webfuse serves only the first connected websocket provider. To allow more than one provider, we have to solve the problem, how inodes are managed:
Each incoming fuse request comes with an inode, used to identify the regarding filesystem object. If only one provider is connected, we can delegate each request to the provider, since all inodes are managed by the same provider.

If more than one provider has to be served, we must delegate the requests depending on the inode value. But this can be tricky, since inodes are currently managed by provider, not by webfuse daemon.

Proposal

To solve this problem without API changes, I propose to use a separate fuse session for each provider. Each session should have its own inode "namespace", therefore we can delegate each request to the correct provider, without the need of any fancy inode management.

To separate each filesystem, I propose to create subdirectories of the mount point. Names could be a session id in first step. A correct naming sceme can be delivered separately - in another feature.

Sounds good?

from webfuse.

For a first implementation your proposal will be sufficient. From usability aspect it would be nicer to have a namespace identifier which can be used to identify the client or better the providing service uniquely.
I think this may lead to API changes.
I was thinking about to propose the clients IP and Port for use as service (namespace/session) identifier, but that will be problematic, when used in conjunction with a reverse proxy. There is still the possibility to forward the client remote information (x-forward-for), but that can be faked.
Actually I think we should start simple, so that the necessary information are provided by the client and validated by the daemon, which acts as kind of service registry!?

from webfuse.

@nosamad: You are absolutly right. Allowing clients to register a filesystem will lead to API changes. A client should be able to register more than one filesystem per session. Therefore, each filesystem needs an identifier to distinguish the target of fuse requests.
Since this is a major API change, I prefer to implement it all together within multiclient branch.

from webfuse.

Multiple clients are supported now.

from webfuse.