Subject: Graphical M*'s

From: [email-masked] (Glenn Crocker)
Date: Thu, 11 Mar 1993 19:38:41 -0800

(Long ago, we would say "MU*"s, but with MOO, I have to say "M*"s
to cover all the bases.  Yow.  Soon, I may have to say, "*"s.  Hmmmm.)

Anyways, I'm one of the TinyMUSH hackers, and am interested in
graphical M[UO]*'s (hey, that's better.).  I understand that there is
work towards this going on in the MOO community, and I wanted to see
if anyone on this mailing-list has any information about:

Who's working on this stuff?
How much do they have done?
What protocol is being used for graphical clients to talk to servers?
What graphical language is being used to represent the images?
etc etc etc.

My basic goal is to be compatible with other graphical M[UO]*'s, since
writing a graphical client is not as trivial as writing a text client,
and it would be _great_ if the various graphical M[UO]*'s could share
clients, images, etc.

I've written support for BSX-MUD's protocol to my MUSH (well, to a
bunch of objects in my MUSH), but it's clearly insufficient.  (2d, 
serious color restrictions, bizarre coordinate system, etc etc etc.)

I'm to the point of seriously thinking about establishing a protocol
and language for these things, so if you've got ideas about this,
please let me know soon.  (i.e. spring break is next week, and I
really don't want to spend _all_ of my time working on my thesis. :-)

(Please note that I'm not on the moo-cows mailing list, so please
reply to me and cc the list, or vice-versa, so I can see your reply.)

Thanks!

-glenn

---

From: [email-masked] (H. Peter Anvin)
Date: Thu, 11 Mar 1993 20:29:53 -0800

> reply to me and cc the list, or vice-versa, so I can see your reply.)

I have had similar ideas, and I have thought about it a lot, although
I have considered it more for BBS use than for MUD.  Of course, the
principles apply just as well to either, and standardization could be
useful to both applications.

My observations have mainly been:

Current text-based BBS's/servers tend to presume extremely little
about their client, which is left to just serve as a login terminal or
at the most provide some elementary ANSI escape codes for text
colorization.

Unfortunately, this puts an extremely large load on the communications
channel (which may be as narrow as 1200 or 2400 bit/s) and on the
server.

However, most people have equipment that not too many years ago would
have been considered large enough to run large corporations.  (A 486
today would have been a 2000-user machine in the 60's)  Since we are
getting rid of the machine independance anyway by doing graphics, we
should put as much of the load on the client end as possible.

In order to provide the client with *useful* intelligence, the server
needs to be able to execute code on the client.  A static set of
functions is too limiting.  Furthermore, it would be useful if the
server could augment the  function library of the client in a semi-permanent
way (code could be stored between sessions).

Compiled languages are unsuitable, because the server will be
dynamically modifying the environment of the client.  For performance
reasons, thus, an interactive, pseudo-compiled language such as FORTH
might be suitable to the task.  FORTH has the additional benefit that
it is a rather simple language to implement.  The basic FORTH language
needs to be augmented with some form of string handling and non-block
disk I/O, but that should be trivial to do.

I suggest string handling is implemented the way it is in C: have any
constant enclosed in quotes be a pointer to a string in static storage
and use library functions for string manipulation.

There is an issue of the security of the client.  Even though it is
probably desirable for the code to access the hard disk of the client
for data and library code storage, it cannot be allowed unrestricted
access (it would make a security hole a mile wide).  I would suggest
that the functions to access mass storage on the hard disk is limited
to a library and a data directory.

These are a couple of thoughts I have had on the implementation of
this.  If you want to discuss any particular aspect, please contact me
directly.

	/hpa

-- 
INTERNET:  [email-masked]   TALK:      [email-masked]
BITNET:    HPA@NUACC     IBMNET:    16331@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  [email-masked]
while ( 1 ) ; cp /dev/zero /dev/null & end

---

From: [email-masked] (Jay A. Carlson)
Date: Thu, 11 Mar 1993 23:08:06 -0800

> writing a graphical client is not as trivial as writing a text client,

Note that we haven't even perfected text clients, since almost all
clients work at the tty-ascii level, which is hardly what most people
think of as `text'---except people who have been brainwashed by unix
and its friends. :-)

See signature.

Jay Carlson
[email-masked]

Flat text is just *never* what you want.   ---stephen p spackman

---

From: [email-masked] (Oh Sung-kyu)
Date: Fri, 12 Mar 1993 02:07:10 -0800

> ....

Yes. I also have the same thought.
And, I found that there is already the system that provides such a environment.
It's NeWS from Sun Microsystems. They developed it as Networking environment
for their computers. it is extended from Postscript to display graphics.
Evenly, it is object-oriended and can handle events and so on.... 
Therefore, it is more powerful than Display Postscript.

But, in spite of its excellent features, Sun decided to use Display Postscript
as the display language of the next version of Open Window.
Display Postscript is nearly the standard of industry because it is from Adobe.

Refer NeWS to get the information about such a environment.

> ...

-hanmaum-