From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <75ea74312ad96f76de8cd4b3291ffb1d@brasstown.quanstro.net> <1e4bfd86eef85bbf4434f8ef22b6fed7@plug.quanstro.net> <948e9cbd967366d058ac8a033ce93f5f@plug.quanstro.net> <53acf6ebfa4f01bbe09d6ed494ef68b1@plug.quanstro.net> Date: Mon, 15 Nov 2010 12:50:01 -0500 Message-ID: From: John Floren To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] p9p factotum available for plan 9 Topicbox-Message-UUID: 804c3a2e-ead6-11e9-9d60-3106f5b1d025 On Fri, Nov 12, 2010 at 3:41 PM, ron minnich wrote: > On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen wrote: > >> Not really, the intent was that servers could implement a subset of >> the .L features, and return Rerror for any that they don't. > > Wonderful! Floren is already fixing plan 9 servers to work this way anyway :-) > Actually, I just have my streaming clients/servers give their versions as 9P2000.s; unrecognized T-messages still get silently dropped. I decided this was a better option for my current work, since it allows me to connect to any unmodified 9P file system, rather than go through and modify every single 9P server out there. That said, I definitely agree that unrecognized T-messages should get an Rerror back; I was kind of grossed out when I discovered that they were being dropped, I had figured that was part of the purpose of Rerror. If 9P ever has to change again (adding new T-messages), you'll find it a lot easier to interoperate old and new code if we get Rerrors on bogus T-messages. John