From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dan Cross <cross@math.psu.edu>
Message-Id: <200101172052.PAA11155@augusta.math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Typesetting
In-Reply-To: <200101170255.f0H2twg01506@egon>
References: <200101162237.RAA05988@augusta.math.psu.edu>
Cc: 
Date: Wed, 17 Jan 2001 15:52:45 -0500
Topicbox-Message-UUID: 4f2835ae-eac9-11e9-9e20-41e7f4b1d025

In article <200101170255.f0H2twg01506@egon> you write:
>> Well, I disagree that it simplifies something which is already simple.
>> Consider creating ``sessions'' over HTTP as an example; I think the
>> methods to do this are ad hoc and complex, if not entirely broken.
>> Using file semantics makes this much easier.
>
>I agree that the current methods for HTTP sessions are poor, but I
>don't see how file/filesystem semantics improves the situation.  Care
>to explain?

Sure.  My original post outlined an idea for using files as endpoints
for IPC in a larger distributed system.  Ie, open a file, you're actually
talking to a process on another system.  Plan 9, of course, already does
this, and Unix has a more limited versions (named pipes, Unix domain
sockets though they're more complex to work with).

Given that, sessions become simple: Open a file, start a session.  Close
the file, end the session.

Implementation wise, it's probably more difficult than, eg, cookies, but
it pushes the complexity down a layer (into the filesystem) where the
application programmer doesn't see it.

As an aside, assuming you can have byte-oriented file operations, the
level of interactivity at that point can go up in the same way it would
going from a 3270 to a VT100 in the terminal world.

	- Dan C.