From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Choate To: <9fans@cse.psu.edu> Cc: Subject: Re: [9fans] WebDAV file system In-Reply-To: <01ea01c27fdb$9a924dc0$620da8c0@HPN5415> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 30 Oct 2002 08:13:35 -0600 Topicbox-Message-UUID: 11fca4ba-eacb-11e9-9e20-41e7f4b1d025 On Tue, 29 Oct 2002, John E. Barham wrote: > Hmmm. I guess I wasn't making myself clear. Seemed perfectly clear to me. I was simply making a point about HTTPD and client-server under 9P and how different it was to 'standard' OS'es. > I want to write a native Plan 9 file system that exposes a remote WebDAV > server in much the same way that ftpfs makes a remote ftp server appear > to be part of the local fs. Rage on. You should spend less time talking ;) > By "stateless" I meant that HTTP creates a new TCP connection... > I don't see how even a (hypothetical) Plan 9 browser could make HTTP > stateful since even if you have fs access to cookies, Who needs cookies under 9P? Nobody, that's who. There is nearly -zero- requirement for a conventional httpd under 9P, therefore there is nearly -zero- need for cookies. Cookies are a convention to let the -server- know where the user has been. If there is no server per se who is going to read those cookies? Nobody. The users client can track all that locally, it only processes html and executes cgi scripts. The trick is the cgi, there are two 'modes' that it can be executed in. The first is conventional cleint side scripts. Pretty easy to impliment, the users browser simply spawns off a process with the apropriate namespace and waits for the results to return from the process cloud. When they do, it renders the page for the user (again via the process cloud since it doesn't need to be done on the users i/o processor). The other approach has to do with server side programs. These require that the user can execute them and grab their i/o stream, but has zero control over reading, writing, or namespace. So, 9P requires that the user be able to see the name of the program and spawn a 'process namespace' off that the user has zero control over (and I admit I'm a little fuzzy on exactly how to do that, right now). Note that all of this doesn't require a cookie, only that the users browser have a pretty conventional 'history' function. This means that 9P is -very- cost effective from the 'server' perspective. Create it, mount it somewhere persistent, and forget about it. Personaly I find the twist that 9P makes to the usual client-server approach to be truly elegent. -- ____________________________________________________________________ We don't see things as they are, ravage@ssz.com we see them as we are. www.ssz.com jchoate@open-forge.org Anais Nin www.open-forge.org --------------------------------------------------------------------