From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Fri, 10 Aug 2007 14:29:56 -0500 From: "Eric Van Hensbergen" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] 9P vs. FUSE In-Reply-To: <5d375e920708101216y225ca5e5oa06270d90e6d4271@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070810114225.GF18939@nibiru.local> <2d66a95ea087868174cfdc519a48a2d7@9netics.com> <20070810123336.GG18939@nibiru.local> <5d375e920708101216y225ca5e5oa06270d90e6d4271@mail.gmail.com> Topicbox-Message-UUID: a5329d1e-ead2-11e9-9d60-3106f5b1d025 On 8/10/07, Uriel 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