From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070908123938.GA3661@nibiru.local> References: <20070908123938.GA3661@nibiru.local> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4213FDC1-61CD-4A86-A293-1840CC1F6017@kix.in> Content-Transfer-Encoding: 7bit From: Anant Narayanan Subject: Re: [9fans] The Web9 Project Date: Sun, 9 Sep 2007 01:08:41 +0530 To: weigelt@metux.de, Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Cc: Topicbox-Message-UUID: bbf16c2e-ead2-11e9-9d60-3106f5b1d025 > Do you dock into the stream handling or use separate functions ? > Would be really cool if you simply can fopen() an 9p resource :) Right now it's just two classes IxpClient and IxpServer; but thanks for the suggestion. Making a stream handler for 9P would definitely be worth it. > Huh, tunnel 9p messages through http ?! Yes. Using Mozilla's XPCOM extensions isn't a very portable solution, and part of the reason web developers choose Javascript is because it is browser-agnostic. The way this works is that the client encodes a series of 9P T-messages into a XMLHttpRequest and the script on the server forwards those messages in-order to the actual 9P service, and responds with a series of R-messages (which the client can then decode). > IMHO, the approach is extending mozilla's stream handling > (nsChannel stuff). > Some time ago a had some look at it. Doesn't seem very trivial. Yes, an nsIChannel implementation was required for this to work. Nothing in Mozilla is trivial - but I will admit that I took longer to learn libdraw than Mozilla's netlib ;) -- Anant