Re: Web for MOO?

• Date: Tue, 31 Oct 1995 02:17:07 PST
• From:
  Andrew Wilson <andrew@tees.elsevier.co.uk>
• Content-Length: 3329
• Content-Type: text

> In message <Pine.A32.3.91.951030172458.52846A-100000@fn1.freenet.edmonton.ab.ca>
> Chris Jones writes:
> 
> > 	Ok.... Does anyone either a: know of a "generic" web to MOO 
> > interface (ie... allowing the viewing of objects from WWW, possibly 
> > interaction from WWW) or b: be willing to send me a web/MOO interface?
> 
> I've made a "sort of a" web server for MOO: MOO/HTTPD.  It will allow people to 
> access readable properties on the WWW Utilities object, and also verbs in a 
> CGI-script-like manner.  I do not have the CGI interface complete, and it 
> currently supports only verbs that run with no input (i.e.: POST is the exact 
> same thing as GET so far).  It only has one directory, the root, and binary 
> files such as images need to be stored somewhere else.  It does work, however.
> 
> You do not have to put a .html suffix on the properties on the MOO, since the 
> parser automatically removes that.  I use .moo as a suffix for MOO verbs in the 
> URL, but not for the actual verb, since it removes that too.

There is no requirement for URLs, which map to HTML text resources, to carry
this '.html' suffix, or any suffix for that matter.  A resource's type is
determined not by the suffix but by the 'invisible' mimeheaders that preceed
the data as it's sent back to your browser.  The webserver should determine
the outgoing Content-type of the resource and send MIME headers back to the
client before sending the real data.

Under UNIX servers (CERN, NCSA, Netsite, Apache et al) this mapping is
enabled by a simple lookup table which the server examines before honouring
each request.  Eg.

1)	You ask for a resource http://foo.com/bar.gif
2)	server sees that '.gif' files should be headed with:

	Content-type: image/gif

3)	server sends back ammended headers immediately followed by the data.

On some systems the logistics involved in maintaining different versions of
graphics images (.gif/.tiff/.jpg), and in 'publishing' the URLs mean that
it's simply easier to maintain a resource:

	http://foo.com/bar

where bar is a generic 'image', of which there are several instances (to
use the MOO terminology):

	bar.gif
	bar.jpg
	bar.xbm

Browsers are able to 'negotiate' with each server they visit to get the
image format they prefer.  I might want a *.gif, and someone on the slow
end of a modem might prefer a smaller *.jpg.  Whatever, we each ask for

	http://foo.com/bar

and the server decides:

1)	which format we most prefer
2)	which formats are actually available
3)	which header to prefix it all with
4)	which bit of data to send

So I'd see:

	Content-type: image/gif

	[contents of bar.gif....]

and Mr Sloooow might see:

	Content-type: image/jpg
	
	[contents of bar.jpg....]

You see this on many Apache-hosted sites, notably HotWired, or the preprint
archive on xxx.lanl.gov.  Other server designs also do this.
 
> I hope to find enough time to accept script input and make directories soon.
> 
> Anyone else who wants a copy, ask me: I've sent the code to Chris.
> 
> Anyone else who wants to help me program it is more than welcome. ;)
> 
> For an example, see http://reality.cs.umn.edu:6464 (currently down due to 
> NetBSD/amiga + LambdaMOO + NCSA httpd instability, but back up or changing 
> location soon).

A marriage made in hell, by the sound of it.

> James Renken

Ay.

• Prev: Re: Web for MOO?
• Next: Re: Web for MOO?
• Index: MOO-cows
• Thread: MOO-cows