From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <AANLkTi=tiVM-irt0L-bqiM-jmpAQ1TU8sz-C2zL9bFFy@mail.gmail.com>
References: <eba624e58560ae3fa25ed54905eb7727@ladd.quanstro.net>
	<75ea74312ad96f76de8cd4b3291ffb1d@brasstown.quanstro.net>
	<AANLkTik0LMeWaT5wo2RRWcrzqRz+RX2a_o45UjcFSMgs@mail.gmail.com>
	<d8838076af10656ad31056e8704f034b@chula.quanstro.net>
	<1e4bfd86eef85bbf4434f8ef22b6fed7@plug.quanstro.net>
	<AANLkTi=6P_m+XM7REhYYiLuRft_UccjVj+SoNH8cZNAR@mail.gmail.com>
	<948e9cbd967366d058ac8a033ce93f5f@plug.quanstro.net>
	<AANLkTi=RGkzqgWmwSjxsa3ok4dB+9LTFWJp+DOzz7o=E@mail.gmail.com>
	<AANLkTikvbZ0puqG=T01ZB6hSGKPmmzBFByU43oFn43A3@mail.gmail.com>
	<53acf6ebfa4f01bbe09d6ed494ef68b1@plug.quanstro.net>
	<AANLkTi=Ay3MzQ4TZO1uJdnD24Tqv-PbOuMzt4fjb+r8Y@mail.gmail.com>
	<AANLkTinT7OKJyhCVh8_5Y0J+d9wtBE8w4yKS1RLa=axQ@mail.gmail.com>
	<AANLkTim7cWNy6t=keucv0gKN+rUDhHA7O8JFh+9ZDMFK@mail.gmail.com>
	<AANLkTinTA00yUuQKDWfqTH3NDgMDq4b1xmLJEY4Xw4vZ@mail.gmail.com>
	<AANLkTik405F5QyOo+amCwMk6_NkRbpZKZb_hvjZy=+Dc@mail.gmail.com>
	<AANLkTi=tiVM-irt0L-bqiM-jmpAQ1TU8sz-C2zL9bFFy@mail.gmail.com>
Date: Fri, 12 Nov 2010 16:12:11 -0500
Message-ID: <AANLkTimsfWdkEamB2j6r3FneN_h06F5tUnvBeujM_SJk@mail.gmail.com>
Subject: Re: [9fans] p9p factotum available for plan 9
From: Russ Cox <rsc@swtch.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=UTF-8
Topicbox-Message-UUID: 7ba49fc0-ead6-11e9-9d60-3106f5b1d025

On Fri, Nov 12, 2010 at 2:55 PM, ron minnich <rminnich@gmail.com> wrote:
> I never much liked .u so I'm happy to see it go away :-)
> But I wonder what the failure of .u says about the version mechanism.

I think it says you shouldn't use it to change the
encoding of existing messages.  Add messages
all you want (and use the negotiation to make sure
you agree on what they are) but don't change the
messages that are already there, and especially don't
change format of fundamental data structures like Dir.

> In the 9p stuff I did in 1998 for linux I used the SunRPC way of
> handling protocol variants: client asked to do an op (e.g. Treadlink)
> and got back an ENOSUPPORT if server couldn't do that.

Sun RPC can get away with that because there are
64+ bits describing a particular RPC request type.
9P has 8.  You shouldn't just send an 8-bit value
and hope the other side knows which one you mean.
You should use the protocol negotiation.

Russ