From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 10 Mar 2000 09:23:19 +0000
From: David Butler gdb@dbsystems.com
Subject: [9fans] Re: 9p question
Topicbox-Message-UUID: 9f0d5758-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <20000310092319.iH33whV7qgZUvdWhoS3ShU9sJMMEYsSjSsjY3uUKLo0@z>

rob pike <rob@plan9.bell-labs.com> wrote in message
news:200003091350.IAA23914@cse.psu.edu...
> > The real reason for the "lengthy" conversation is the Tclone/Twalk
> > part.  That is part of the price that is paid to remove the '/' as a
> > directory separator
>
> No.

Is that 'no' the conversation is lengthy, 'no' that it is part of the
price to remove '/' or 'no' that removing '/' was a goal?

[snip]
>elements (requiring the server to parse and understand '/'), but
>it's such a pain to change the protocol.

I hope if you though it "better" it would be worth the "pain".
(Not that I think it "better", I don't.)

[reorder]
>    The real reason is that after each walk the client must check whether
>the point-so-far is in the mount table.  That's why it's done a path

[snip]

>Seeking on a directory is forbidden because it's hard enough to
>implement reading a union directory without seek. The internal

By your own point union directories are handled in the Twalk.
What does that have to do with reading a directory?

>structure that must be maintained in the kernel was deemed too
>hard to maintain other than by sequential access, so we made
>seeking on a directory illegal.  It didn't seem worth the implementation
>overhad.

Back to the better/pain discussion, again.  I thought the limitations
to restrictive and worked out a better one.  Yes, it was painful, but
the result was well worth the effort.

>            I still feel that way.

I'm glad.  I won't have to integrate a conflicting solution when,
if ever, Release II(TM) sees the light of day...