From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <140e7ec30811111842j10417ed3pe9700f64daee68e3@mail.gmail.com> Date: Wed, 12 Nov 2008 11:42:59 +0900 From: sqweek To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7c5efb383a86c1daae7144dc8e310d5b@9netics.com> Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 3ccf3f8c-ead4-11e9-9d60-3106f5b1d025 On Wed, Nov 12, 2008 at 1:52 AM, Eric Van Hensbergen wrote: > On Tue, Nov 11, 2008 at 10:36 AM, Skip Tavakkolian <9nut@9netics.com> wrote: >>> I just want to have >>> separate protocol ops for messages versus a single extension op. I >>> suppose the difference is largely an implementation decision assuming >>> your protocol operation space is large enough >> >> the thinking is that it's the least polluting -- in regard to 9P >> messages -- while still allowing for many categories of ops. >> >> but almost immediately there has to be a standard for the >> extension message content. maybe it could be XML/SOAP :) > > I guess the difference between > > > > and > > Text > > is lost on me. What's the current default behaviour for unknown message types? I'm guessing existing servers would respond with Rerror. Since you want to forward unknown ops, I think this makes a case for Text/Rext - it's a simpler modification to forward Text messages than forward all message types within a certain range, especially if other protocol changes happen in the future. OTOH, I guess the idea is a minimal change to the plan 9 routines to forward unknown messages, rather than educating it about the different types. In that case there isn't so much difference, though I'm not sure how you tell whether a particular server is an endpoint vs a transitive mount - seems you'd have to add a flag to lib9p and at that point you seem to have less to worry about if you just educate it about Text/Rext... -sqweek