[Prev][Next][Index][Thread]

# Re: Web for MOO?

- Date: Tue, 31 Oct 1995 02:17:07 PST
- From:
- 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

Home | Subject Index | Thread Index