From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20101115032531.GB27578@opal.ai.ki> References: <20101115032531.GB27578@opal.ai.ki> Date: Mon, 15 Nov 2010 07:44:51 -0800 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016e6464d1a24dd160495195260 Subject: Re: [9fans] 9p vs http Topicbox-Message-UUID: 7ed4ea88-ead6-11e9-9d60-3106f5b1d025 --0016e6464d1a24dd160495195260 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 14, 2010 at 7:25 PM, Sam Watkins wrote: > hi, > > I am wondering what you think about the capabilities of 9p compared to > http/1.1. Perhaps this seems like an odd comparison, but I think 9p and > http > are broadly similar in purpose and functionality. While writing a simple > webserver, I got to thinking that http is really a very capable protocol. > > http is text-based, it supports pipelining and arbitraty metadata. As far > as I > know, 9p does not support pipelining nor arbitraty metadata. It seems to > me > that these are big advantages for http. 9p supports walking; are there > other > things 9p can do which http cannot, which give 9p a significant advantage? > > Am I correct, that 9p does not support pipelining? I suppose this would be > a > big problem. For example, with http pipelining one may ask a server to > HEAD > (like stat) 10,000 files together, without having to wait for the > responses. > Over a high latency link (e.g. Australia -> USA), this might save perhaps > an > hour of waiting. > Under certain situations, 9p can do some forms of pipelining. The tagged requests don't have to be waited on in order, for the next outgoing request to be sent, unless there's a dependency of one completing before the other, or the evaluation of completion of a previous one on another. > > Such an asyncronous interface might be useful even when accessing local > disks - > if the filesystem receives 100 open/read/stat requests bundled together, it > might optimise disk access to minimise seeking, as is commonly done for > writes. > > By the way, I read the other day on this list that there is no need to > improve > cat(1). Well for me, I still feel that the command `cat` without args > should > concatenate 0 files (producing no output), not copy stdin to stdout! > That's an interesting point of view. I think the concept of "standard input" is that if no input is given, it was going to be the fallback. Same goes for standard output. With that said, I think cat is behaving just fine to take no arguments and then default to the standard input and output :-). > > > Sam > > > --0016e6464d1a24dd160495195260 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Nov 14, 2010 at 7:25 PM, Sam Wat= kins <sam@nipl.net= > wrote:
hi,

I am wondering what you think about the capabilities of 9p compared to
http/1.1. =A0Perhaps this seems like an odd comparison, but I think 9p and = http
are broadly similar in purpose and functionality. =A0While writing a simple=
webserver, I got to thinking that http is really a very capable protocol.
http is text-based, it supports pipelining and arbitraty metadata. =A0As fa= r as I
know, 9p does not support pipelining nor arbitraty metadata. =A0It seems to= me
that these are big advantages for http. =A09p supports walking; are there o= ther
things 9p can do which http cannot, which give 9p a significant advantage?<= br>
Am I correct, that 9p does not support pipelining? =A0I suppose this would = be a
big problem. =A0For example, with http pipelining one may ask a server to H= EAD
(like stat) 10,000 files together, without having to wait for the responses= .
Over a high latency link (e.g. Australia -> USA), this might save perhap= s an
hour of waiting.

Under certain situatio= ns, 9p can do some forms of pipelining. =A0The tagged requests don't ha= ve to be waited on in order, for the next outgoing request to be sent, unle= ss there's a dependency of one completing before the other, or the eval= uation of completion of a previous one on another.
=A0

Such an asyncronous interface might be useful even when accessing local dis= ks -
if the filesystem receives 100 open/read/stat requests bundled together, it=
might optimise disk access to minimise seeking, as is commonly done for wri= tes.

By the way, I read the other day on this list that there is no need to impr= ove
cat(1). =A0Well for me, I still feel that the command `cat` without args sh= ould
concatenate 0 files (producing no output), not copy stdin to stdout!

That's an interesting point of view. =A0I= think the concept of "standard input" is that if no input is giv= en, it was going to be the fallback. =A0Same goes for standard output.

With that said, I think cat is behaving just fine to ta= ke no arguments and then default to the standard input and output :-).
=A0


Sam



--0016e6464d1a24dd160495195260--