Ideas for the future
Thomas A. Fine <fine@cis.ohio-state.edu>
Date: Tue, 1 Dec 92 19:57:14 -0500
From: Thomas A. Fine <fine@cis.ohio-state.edu>
Message-id: <9212020057.AA18034@soccer.cis.ohio-state.edu>
To: www-talk@nxoc01.cern.ch
Subject: Ideas for the future
X-Mailer: Perl Mail System v1.1
Idea 1. HTML (Just a nice feature)
------------------------------------
I'd like to be able to PUT files onto remote sites.
The idea is, that documents might be maintained by people at different
sites. As it is, they have to coordinate updates through email, and it's
generally a pain. What you'd want is to just connect, get the docuement,
edit it, and put it back. (Ideally, you'd have an editor built into your
browser to do this, but that's another problem.)
(BTW, Is the only proposed new HTTP stuff in
http://info.cern.ch/hypertext/WWW/Protocols/HTTP.html ? I couldn't find
anything mentioning either disconnection or end of document in that proposal)
PUT docuement
If you don't have permission -> Permission Denied
If the file already exists, and you don't have a lock -> Document not locked
Otherwise, the server would return READY, the client would send the
data, unlock the file (if locked), and disconnect.
LOCK document
If you don't have permission -> Permission Denied
If the file doesn't exist -> No such document
If the file is already locked -> Document already locked
Otherwise the server marks the document as locked, and returns a copy to you.
If you want to keep the server stateless, then you can't store lock
information. This means you have to do the LOCK and the PUT in the same
connection. This has the advantage that you can't possibly have stale
locks - if the connection dies, the lock is automatically deleted. But
you can no longer rely on a disconnect to mean end of document. You'd
have to make another addition to the protocol - the response from the server
would have to include the size of the document about to be transmitted.
The other disadvantage to this is that editing may take a while -
On the other hand, if you are willing to make the server stateful, then
you could still rely on disconnect to mark end of document, in the case of
PUT the disconnect would come from the client. Of course, with a stateful
server, you'd have to expire the locks after a couple of days, in case some
bozo forgot that he started to edit something.
Note that this will also gunk up your config file with access control stuff,
especially if you want to selectively control write access.
This could potentially be useful for setting up free areas where anyone
can document anything they like - we hope to set an area up like this here
for local use, just to see if anything develops from it (but we still need
a good editor).
Also, this might make a useful way to discuss things like this - rather than
responding to my article, you could just add anchors to it in appropriate
places that point to your response(s).
Idea 2. HTML/HTTP (something I think is needed)
-------------------------------------------------
When you get lots of good documentation into WWW, there's going to need
to be some guarentee of access to that information. The best way to
do that is with multiple servers. From an HTTP standpoint, that only
requires another attribute (or list of attributes if > 2 sites) be added
for fallbacks:
<A NAME=id1 HREF=//info.cern.ch/hypertext/ImportantDocument
FALLBACK=//www.cis.ohio-state.edu/hypertext/ImportantDocument> ... </A>
or you could add numbered HREFS, or call them IREF, JREF, etc. :-), doesn't
matter. (Or can you even have multiple attributes with the same identifier?)
I see this being used in two different ways. In the first, a single site
would run servers on more than one machine, in case one goes down. The
physical data would all be on the same disk(s), but mounted on both machines.
In the second, different sites would provide mirroring of information,
for instance, Ohio State would GET all of cerns documents and store them
locally, and cern would include references to ohio state.
This looks like it might complicate things if we have implemented LOCK
in the protocol. In the second case, no problem. Cern is the master,
Ohio State just picks things up from cern. In the first case, we can
solve the problem similarly - configure one server to allow editing, and
one to be read only. Then if the main server goes down, you have no
editing capability but you can still view the data.
Lastly, a good idea even if you don't implement multiple servers: ping the
site before you connect.
Idea 3. Documents
------------------
Once we get things more settled, a good showcase for this system, and
one that would really sell "The Net" on it, would be to convert all of
the newsgroup FAQs to html documentation. This wouldn't exactly be a
trivial task (perhaps we could recruit some FAQ maintainers to help)
but it would be of enormous value. We could start on it now, and have
it ready together with the software.
tom