Subject: Graphical Clients again.

From: Colman Reilly <[email-masked]>
Date: Mon, 30 Aug 1993 09:25:03 -0700

This is what I'm doing.

Colman.

----------------------------

                           A HTTP-AWARE MUD CLIENT.
                                       
Introduction

   I have written a prototype MUD client that deals with the the problem of
   displaying graphical information on the MUD by using the http protocol to
   retrieve pictures from a http client separate  from the MUD.
   
   The client is at the moment written using Extened Tcl and Tk and is
   therefore not very portable. I am working on rewriting sections of it so
   that it only needs Tcl and Tk to compile. It should be ready soon.
   
   The client is not intended to provide hypertext within or around the MUD,
   but is intended to use the http protocol already available to allow access
   to graphics in a simple and easy on the server way.
   
    This is written for both the MOO and WWW audiences so excuse me if I
   explain one to the other.
   
HTTP and WWW.

   From "Internet Resource Discovery Services", ftp:
   caldera.usc.edu:pub/kobraczk/ieeecomputer.ps.Z
   
   "The World-Wide Web or WWW merge information discovery and hypertext. WWW
   organises data into a distributed hypertext, where nodes are either full
   text objects, directory objects or indices.
   
   The WWW architecture is based on the client-server model. The client
   provides users with a hypertext-like browsing interface. Besides it's native
   HyperText Transfer Protocol, WWW clients understand ftp and NNTP. . . .
   
   HTTP allows document retrieval and full-text search operations. HTTP runs on
   top of TCP and maps each request to a TCP connection. HTTP objects are
   identified by the HTTP protocol type, the corresponding server's name and
   the path name to the file where the objects' contents reside."
   
   It is important to note that a WWW clients which can deal with HTTP are
   available for a large number of different machines.
   
The Client

   The client I am writing works by picking out references to http objects from
   the text stream output by the MUD and displaying them using a slave HTTP
   browser, for example xmosaic from the NCSA. (In fact at the moment this is
   the only http client it can use.)
   
   In practice this means that you have a number of separate windows on
   screen: the text connection to the MUD and the xmosaic session displaying
   graphical objects.
   
Why do it this way?

   My main reason for writing this is to allow lectures to be given in virtual
   classrooms.  I would envisage an instructor preparing slides in advance,
   making them available through a http server and pointing students to them
   through references in class. (People without graphical clients could
   download and print slides before the lecture.)
   
   The other obvious use is to allow hypertext exhibitions in a virtual
   gallery. The http references can as easily point to an MPEG movie as
   anything else - allowing easy reference to online videos. Something I'm
   working on as a demo is to build a gallery of chaotic pendulums. You look at
   a pendulum, read the description and , if your client is http-aware, the
   movie pops up on screen.
   
   Of course ordinary graphics can easily be embedded in http references and
   picked up for display.
   
Support within the MUD

   Taking the example of a MOO, the easiest and cleanest  way  to do this is to
   have an extra property on players, say player.http-aware and a http-room and
   http-object, which display an associated http reference, of the form  ,
   which the new client would pick out and pass on to xmosaic.
   
   This means that the MOO is doing almost no work to support the graphics,
   which given the amount of resources a MOO eats anyway isn't a bad thing.
   
Colman
     
-------
Colman Reilly ,School Of Mathematics, Trinity College, Dublin 2, Ireland.
[email-masked]
(Home)+353-(0)1-8204643 (College)+353-(0)1-7022280 PGP Public Key on Request