On 27 February 2013 08:24, <mycrof...@sphericalharmony.com> wrote:
> I hope this post leads to constructive discussion of the import/exportfs
> protocol.
As you'll have noticed, it isn't a great protocol as it stands. I don't
think your option makes it worse.
Thanks for the detailed discussion. I think at least one existing system
already does what you say, using the -m option ([just] mount, skipping the
tree spec),
and if you were to use that in a patch to sources, then eventually that
private change could be eliminated.
Note that in your example
import -z tcp!server!9876 somefiles /n/authedimport
with the existing import you don't need to specify the (now unused)
somefiles. If I write {import system /net} it sends "/net" as the tree by
default.
I think all you'd need to do to make the option tidier is to reject the
case argc == 3 in the relevant switch if the option is set. Then you could
write
(changing the option letter):
import -m tcp!server!9876 /n/authedimport
which reads as import by mounting the 9P service on the given connection on
the given mount point. It's otherwise a little strange to have an
argument (your "somefiles") that's completely ignored.
As you say, this could also reasonably be an option to srv to authenticate
its connection to a remote exportfs, but the fewer commands that know
this particular protocol, the better, and both import and exportfs already
do that.
