9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Eric Van Hensbergen" <ericvh@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] 9P vs. FUSE
Date: Fri, 10 Aug 2007 14:29:56 -0500	[thread overview]
Message-ID: <a4e6962a0708101229l6d62abe3idfd28b0181b8ab3f@mail.gmail.com> (raw)
In-Reply-To: <5d375e920708101216y225ca5e5oa06270d90e6d4271@mail.gmail.com>

On 8/10/07, Uriel <uriel99@gmail.com> wrote:
>
> Strange, this is not what I remember from IWP9 at all. What I remember
> is that pretty much all requirements people had could be accommodated
> *without* changing the existing 9p2000 protocol by using conventions
> on special attach names to provide access to extra required
> functionality or other such tricks (the exception was the idea of how
> to group messages, which unfortunately nemo seems to have discarded
> but I still think is so far the only real improvement 9p might need,
> and it could be largely backwards compatible)
>

(Sigh)

IIRC there were several proposed extensions such as caching, security,
(and perhaps extended attributes) that could be done under alternate
aname semantics.

However, for more complicated experiments (such as the message
groupings) would use new operations which could be easily filtered out
by servers which didn't support them instead of the mess we have with
.u and different operands for existing operations.

>
> Of course, my memory could be wrong, but it would be really sad to see
> yet another 9p variant pop up after the .u debacle when I think the
> consensus was clear that 9p could handle just fine pretty much
> everything everyone wanted (again with the exception of the message
> grouping for high latency links).
>
> In any case, it would be nice if people considering changes to the
> protocol could be a bit more open about it so we could have some
> discussion about how much sense it makes, and we could avoid a repeat
> of the waste of time and effort with .u.
>

Yes - you are right, its much better to work things out in committee
versus actually write some code to figure out how things work out in
practice.  That's just the way its always been done in Plan 9.  And so
many people had so much time wasted in the .u effort -- all those
hundreds of programmers working thousands of hours on adding .u
support, all for nothing.

Oh, wait -- there was only one other programmer working on this stuff
besides me, sorry lucho.

Vote with your code, otherwise please keep to your elite "development" lists.

         -eric


  parent reply	other threads:[~2007-08-10 19:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-10 11:42 Enrico Weigelt
2007-08-10 11:57 ` Skip Tavakkolian
2007-08-10 12:19 ` Iruata Souza
     [not found] ` <2d66a95ea087868174cfdc519a48a2d7@9netics.com>
2007-08-10 12:33   ` Enrico Weigelt
2007-08-10 12:36     ` erik quanstrom
2007-08-10 12:42       ` Lucio De Re
     [not found]     ` <22bce9d3afa44ed70b739ea77d5d8046@quanstro.net>
2007-08-10 12:48       ` Enrico Weigelt
2007-08-10 13:18         ` erik quanstrom
     [not found]         ` <f17c25af999bb93211e069e6109bb154@quanstro.net>
2007-08-10 13:36           ` Enrico Weigelt
2007-08-10 13:42             ` andrey mirtchovski
2007-08-10 13:44             ` erik quanstrom
2007-08-10 13:45     ` Eric Van Hensbergen
2007-08-10 15:51       ` ron minnich
2007-08-10 16:32         ` Latchesar Ionkov
2007-08-10 16:39           ` Eric Van Hensbergen
2007-08-10 18:16           ` ron minnich
2007-08-10 18:25             ` Latchesar Ionkov
2007-08-10 18:35               ` Eric Van Hensbergen
2007-08-10 19:16       ` Uriel
2007-08-10 19:21         ` ron minnich
2007-08-10 19:29           ` Charles Forsyth
2007-08-10 21:57             ` ron minnich
2007-08-10 19:29         ` Eric Van Hensbergen [this message]
2007-08-10 19:32         ` Latchesar Ionkov
2007-08-10 19:02     ` Uriel
2007-08-10 19:21       ` Charles Forsyth
2007-08-10 19:26         ` erik quanstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4e6962a0708101229l6d62abe3idfd28b0181b8ab3f@mail.gmail.com \
    --to=ericvh@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).