From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <29302f743a99f05c1d9ac196b0245f81@9netics.com>
To: 9fans@9fans.net
Date: Tue, 11 Nov 2008 07:37:43 -0800
From: Skip Tavakkolian <9nut@9netics.com>
In-Reply-To: <1226365206.17713.390.camel@goose.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Do we have a catalog of 9P servers?
Topicbox-Message-UUID: 3bc04744-ead4-11e9-9d60-3106f5b1d025

> This approach seems to be flawed on two accounts:
>    1. it forces the server to resolve symlinks and special
>    nodes, without an option for the client to do the same.
>    That prevents cross-tree symlinks and nodes as the
>    points of rendezvous *on the client*. IOW, the following
>    will not work:
>       $ mknod <imported FS>/test p
>       $ echo test >> <imported FS>/test &
>         cat <imported FS>/test
>    I can buy a point of view that reading on a node that happens
>    to be a character device should really bring the data from
>    the remote server's device attached to that node. However,
>    that point of view is much more difficult to sell for
>    FIFOs.
>
>    2. It doesn't let manipulate these special files. IOW,
>    readlink(2) fails and so does mknod(2)/symlink(2).

operations like these (symlink, readlink, lock, etc.) that only have
significance at the extremities should not worry the transit relays.
that was the reason for Text/Rext proposal.

regardless, interpretation of the ops in a hetergeneous environment
will be a problem.