textfiles/computers/CYBERSPACE/cyberter

Article 4307 of sci.virtual-worlds:
Newsgroups: sci.virtual-worlds
Path: news.u.washington.edu!milton.u.washington.edu!hlab
From: snoswell@ucs.adelaide.edu.au (Michael Snoswell)
Subject: TECH: Info on CYBERTERM Open System (long)
Message-ID: <1992May31.221443.12742@u.washington.edu>
Originator: hlab@milton.u.washington.edu
Sender: news@u.washington.edu (USENET News System)
Organization: Information Technology Division, The University of Adelaide, AUSTR
Date: Sun, 31 May 1992 16:24:54 GMT
Approved: cyberoid@milton.u.washington.edu



Following is the document I promised a while back on the system I am
developing. I have received many requests for this data so here it is
(a little incomplete or it never would have been posted). I'm emailing
copies to those who requested it and will be in touch with programmers
who said they were interested (see later).

---------------------------------------------------------------------------
                                  
                                  OSC
                         Open System Cyberterm

THIS DOCUMENT

This document is an overview of ideas and concepts that have evolved
over the last year or so. It is not meant to comprehensive, exhaustive,
complete or fixed. Any items mentioned herein are open for discussion
and modification through arbitration (ie if you've got a good idea, tell
me and we'll use it!). Criticism is most wellcome as this has chiefly
been only a two person project with various input from 1/2 dozen others.
Arguments and pointers from others would be gratefully received.

The first part of this document discusses some broad ideas and then
gives a brief description of the terms used. Following this is a 1/2
technical discussion on a walk though of some aspects of the system.
After that a more detailed examination is made of the various terms
described briefly earlier and finally a look at other, less related
topics is covered in cursory fashion.

After all that a brief description of the software as it stands is
given, along with projected milestones and pleas for
technical/programming assistance.

This document mentions many ideas and concepts that stem from the use
and implementation of the underlying protocols. This paper discusses
broad uses of the protocols and the resulting system rather than
focusing on the protocol itself. The reason for this is two-fold:

  1) The protocol by itself would seem pretty meaningless without 
     describing how it works and how its resulting use affects the 
     dynamics of a system, and 
     
  2) The protocol isn't firmly set. As the system is developed, more 
     holes are found and things change. There are 1 dozen or so basic 
     messages and a dozen or so rules that are followed, but these are in flux.

It is hoped that this paper will give readers some familiarity with the
type of system that is beeing aimed for. A later paper, covering the
nitty gritty may be produced, but the detailed explanations may be left
to the source code itself when it is released. 

Having read this discussion first, users and programmers will be in a 
better position to criticise and aid in the systems development (by 
discussion and programming support).

Note: Where possible I have put terms in capitals which refer to 
concepts/objects whichare peculiar to this system. This is to try to 
differentiate items when using English to describe some ideas etc, to 
make things a bit clearer.



SYSTEM OVERVIEW

The need for a low cost, low bandwidth cyberterminal (CYBERTERM) has 
arisen due to the increasing need to communicate over existing data 
channels with existing hardware. The system is aimed for widespread use 
over a number of platforms and data connections. Initial release is planned 
for late '92 in a shareware format with full source code for all available 
systems.



INTERFACE

The interface is simply using the screen with the keyboard and mouse to 
provide a window view into a cyberspace area. As source code will become 
available. 

The addition of Power Glove, HMD and other devices will be 
encouraged but not initally supported and will not be required. 

The nature of the system will be such that if you have a PC XT with 
hercules graphics then you can display only wire frame at 1 frame per 
second (or whatever the software can manage). If you have an Indigo or 
similar then you are lucky enough to be able to display 30 frames a second,
solid or rendered. The idea is that all the different systems will be able to be
functionally connected together in a meaningful manner. If you have a full 
body suit, lucky you and you get better integration into the cyberspace etc etc 
etc.

What this all means is that the code has a central communications core that is 
common to all modules on all systems. The interface business is merely a 
variable front end. All systems will use the same messages etc to 
communicate, but the low end users' systems will not request the extra data and 
will not be capable of producing some messages. 
(eg if you don't have a mouse then movenment is via keyboard. If you have a 
Data Glove then movement can be via gestures).



INITIAL SYSTEM

The system will initially be designed around a PC, with Amiga and X11 (on a 
Sun IPC) mods being made as we go, but with no special provisos for these 
machines at this point. Software is currently being written and a beta version 
will be available in a few months (now is May '92). Release will be via 
request to selected users for immediate feedback, followed by general 
shareware release.



SYSTEM ARCHITECHETURE

The whole nature of the cyberspace is controlled by the messages that are 
sent, which abstractly define the rules for objects, clients etc within the 
cyberspace. To more clearly describe the nature of these rules and 
messages, a number of terms have been borrowed and coined to describe 
new/borrowed concepts. Once these terms are defined, then it becomes 
much clearer as to how the whole thing fits together and the interaction of 
objects and the nature of this interaction will become evident as you 
understand the rules and contraints which define the behaviour of the 
cyberspace.



DEFINITIONS

These definitions are brief and are given to allow a fuller understanding of
the descriptions to follow. A more detailed discussion of these terms
will follow later.

CLIENT

A CLIENT is the term to describe a person (USER) who is connected to a
system. The CLIENT may be automated (an AGENT).

SERVER

A SERVER is the central message handling facility which handles the data
flow between CLIENTS. (A bit like a BBS)

LOCAL SERVER (LS)

A LOCAL SERVER is a SERVER that resides on the same machine as the
CLIENT.

REMOTE SERVER (RS)

A REMOTE SERVER is not at the same physical machine as the CLIENT in
question.

CYBERTERM (CT)

This is the term to define the CLIENT and the LOCAL SERVER together which a USER
interfaces to. This all resides on his local machine.

SECTOR

A SECTOR is a region of CYBERSPACE which is controlled by a single
SERVER.

SECTOR CONTROLLER (SC)

This is another term for the SERVER, but which covers the CLIENT that is
local to that SERVER (akin to a News conference moderator or a BBS
sysop).

PERMASPACE (PS)

PERMASPACE is an area of the SECTOR which has been allocated to a
specific purpose. The data defining this region resides in the SC which
controls the SECTOR.

PRIVATE PERMASPACE (PPS)

PERMASPACE can belong to a single CLIENT (or else it belongs to the SC). If a
USER acquires a region of a SECTOR for their own use, that region is
called PRIVATE PERMASPACE and is controlled by the owner CLIENT's LOCAL
SECTOR CONTROLLER (ie the SERVER which resides on their own machine).

LINE

A LINE is the connection from the SERVERs to the CLIENTS, LINEs can be
virtual or real.

AGENTS

AGENTS are macros that use the messages and protocols of the system to
perform tasks as the USER himself would. There are 3 types of AGENTS
defined so far. PRIVATE AGENTS, SC AGENTS and INDEPENDENT AGENTS.

ASPECT

ASPECT is the description of an OBJECT and covers visual and audio
definitions in an extensible hierarchy of increasing complexity. All
objects have default ASPECTs.

CYBERSPACE CONFERENCING (CBC)

This is the initial "let's get together and have a chat" aim of the
system and is useful when people ask "So what are you working on?". You
say, "I'm working on a Cyberspace Conferencing system", or something
like that.

GUEST

A GUEST is a CLIENT who is remote to your location who is connected to
your LOCAL SERVER.

BBS

A bulletin board system, which when in "chat" or "conference" mode is a
good analogy for what this system will build upon (ie a graphical
version of a BBS CB channel.)

OBJECTS

OBJECTs are any things which exist within a SECTOR and and listed in a
SERVER database. This includes CLIENTS, AGENTS, PERMASPACE etc.

ID

ID applies to AGENTS, CLIENTS and SERVERS. It is a unique 4 byte number
where the top 4 bits define what type of object the ID belongs to.

FAR - 1,000 units
NEAR - 100 units
CLOSE - 10 units
VERY_CLOSE - 1 unit (ie 26 adjacent units)



A DEMONSTRATION RUN THROUGH

Perhaps the best way to show how the various features of the system interact
is to give a description of a typical session. This description will not
be exhaustive and will give some technical details of the message
passing that will take place during such a session. A complete
description of all the features will not be given here as that would
take too long and this is only meant to be an overview. However, what I
hope is to be able to give some insight into what the working system
will be like.

So here we go.
(by the way this description is of a screen and keyboard system, but as
stated above, you can use whatever hardware/imagination you have
available)

First off when you start up the CYBERTERM you have a blank screen with maybe 
a few control buttons around the edges. 

The first step is to log into the LOCAL SERVER. Now this is a SECTOR 
CONTROLLER that resides on the same machine and in the first incarnation of 
the software is all in the same executable. 

This connection is done by hitting the 'connect' key
(or mouse button etc). This will send a REQUEST_TO_ENTER message to your
LOCAL SERVER, but first the interface will require that you enter some
parameters. These are:

  1) your proposed entry point into the LOCAL SECTOR, and 
  
  2) the proposed viewing direction. 
  
In a more advanced system these parameters will probably be pre-set in 
an option menu so you don't have to enter these details each time, but 
that's the way it is now 

(Note: There are quite a few places where things can be pre-set like 
this, as you'll see).

Once the CLIENT software has assembled this data it sends the message to
the LOCAL SERVER prepended by your ID, a unique identifying code (4
bytes) that defines you as a human CLIENT as well as giving you a unique
handle for reference purposes. An additional parameter, velocity, is set 
to zero and is the final part of the message. 

The connection between the CLIENT and the LOCAL SERVER is a buffer 
that emulates a LINE. 

A daemon type function transfers the message across to the SERVER's input 
(and visa versa). 

The reason this is done is so that the software for a REMOTE SERVER and 
the LOCAL SERVER will be the same, except that the daemon will be 
different (ie transfering data to and from a modem, serial line, socket, 
or whatever). So as far as the SERVER is concerned it is running 
autonimously from the CLIENT and the human interface handling software.

The SERVER checks its internal database of objects to see if you are
allowed to enter at the specified point (more on that in a moment) then
sends a MOVE_TO message back to the CLIENT. This includes the CLIENT's
ID to make sure the right person gets the message (not necessary
obviously as you're the only one logged into your machine), a location
tuple, a direction tuple and a velocity tuple (which is zero in this
case). Now it looks like we're already sending redundant information, but
these are generic commands that can apply to many situations.

You CLIENT software now gets this MOVE_TO message and can throw up
an image on the screen which shows what the SECTOR looks like from this
point.

What's there to display? Well by default the 'floor' of the sctor is
blue and can be displayed as a grid. The range of co-ords is 2**16
(32768) only positive, as a 32 bit fixed decimal number. This
effectively gives a cube 32768 units on a side. That seems small but
think of each unit as one metre. This means the SECTOR is about 32kms
cubed, with increments down to 1/30 mm. I really think this will cator
for system (and user) requirements for a long time to come. There is
room for much more detail than this actually (2**32 time more) as is 
shown later under PRIVATE PERMASPACE.

Okay, so we see a blue grid below us. Our CLIENT software is keeping
track of our velocity and co-ords at the last vector change (ie time
stamped) in its internal object database (this is separate from the 
SERVER's  object database). So a simple look at the time and a scan of 
the database will give the current location of all objects and the 
screen can be updated accordingly. If your machine is slow this screen 
update is slow etc.

Now that you're logged into the LOCAL SERVER things get a bit more
interesting. To make things a bit clearer I'll skip over the details a
bit here and get to a remote connection.

Suffice to say that the objects contained in the LOCAL SERVER all belong
to your PRIVATE PERMASPACE. There may be objects here, for instance that
represent your hard disk and so you may have a graphical operating system
where you can move files, launch applications etc. You can construct
objects and store them for later use. Certain areas may be defined as
dorrways to the control of real-world apparatus by telepresence etc. So
you now have your own SECTOR, a whole world really, in which to create
and move. Now all this on your own machine is nice but dull.

The next step is to send a TRANSFER_SECTOR command. This will move you
to another SECTOR. This will obviously be a REMOTE SECTOR. It's up to
you to specify a legal SECTOR you wish to transfer to and it's up to
your LOCAL SECTOR CONTROLLER to know how to connect to the SECTOR.
Asumming all this has been set up your LOCAL SC (for modem) dials up the
remote SC and identifies itself as an SC that has a CLIENT that wants to
enter. This is sent as a REQUEST_TO_ENTER command (as before). Your
CLIENT software knows that to issue a TRANSFER_SECTOR message you must
enter a location and view direction so it prompts you for them (or gets
it from pre-set options as before). The local SC passes the info on to
the remote SC. If the request message is okay, a MOVE_TO command is
sent from the remote SC to the local SC which now knows that any data
coming in from the CLIENT (on LINE x) is transfered straight to the
remote SC (on LINE y) and visa versa.

Now that your CLIENT software has a new location and viewdirection it
adjusts it's internal object database and updates the screen accordingly
(the blue grid). 

When you entered the SECTOR the SC sent a message of its own to all 
other users who are within NEAR (100 units) of where you entered.
These messages say what your ID is, your vector and location (this is
actually a PERSONAL_ASPECT_DATA message which has ID, vector and
location in the front of the message but without the ASPECT data as the
SC doesn't have this yet). 

These other users may have their systems set up to ignore these 
(unexpected) messages, but if they process them then you, 
the new user, will appear on their screens in the appropriate place and will be
placed in their individual object databases. They may also have a
database of 'know ASPECTS' and can check to see if they already know
what you look like and so can display you in your full glory straight
away. Alternatively they may have their system set up to automatically request
your APSECT if it is unknown and to display it then.

Anyway, you've just entered this REMOTE SECTOR.

Now you can send a message (or a more sophisticated system would be
pre-set) to ask the REMOTE SC what the brief details are of all users
within NEAR of your location (that is, to send you PERSONAL_ASPECT_DATA
messages with ID, vector and direction). This data is added into your
CLIENT's object database (with a time stamp) and the objects appear on
your screen with the default ASPECT. You can request the details of
other users over different distances first off if you like. Once you know
the ID of other users you can REQUEST_ASPECT_DATA of a specific ID, to
whatever level of detail of ASPECT the REMOTE SC has in it's database.
So on your screen these other users appear as arrows (their default
ASPECT) or their real shape. 

When you move (that is, change your velocity or direction) your CLIENT
automatically sends a message (MOVE_TO) to the SERVER. If this is okay by
the SERVER then it sends a MOVE_TO message to you telling you where to
move to (the reason for this is made clear later) and then the SERVER 
distributes the message to all NEAR CLIENTS. In this way, as you watch 
your screen with these objects moving around in straight lines until 
they change vec/vel when you get a message from the REMOTE SC telling 
you their new velocity/direction. If you turn around your system sends 
a MOVE_TO message that is distributed and others see your shape turn around etc.

It is important to note that there is no collision control and it is quite
possible for you to move straight through someone else. 

(Note: The only possible exception to this is stopping over a PERMASPACE
unit you do not own (see later) or the possiblity that two CLIENTS
cannot be at the same point at the same time. There is no logical reason
why this could not be so, it's just that it doesn't see right to me.
Being instantaneaously at the sam epoint is okay, (ie moving through
each other), but being stationary at the same point? Comments please.)

An optional message that you can send to the SC is CHANGE_UPDATE_RATE 
which tells the SC how often to send you location, vel and vec updates 
of all CLIENTS within a given distance of yourself. Normally you would 
have to request this information specifically and the position of users 
you see on the screen may be false (for example a user may drift out 
of the NEAR distance from you but your object database is still tracking 
them saying they are moving at such and such a vector and speed when 
actually they may have changed direction etc. So with a CHANGE_UPDATE_RATE 
message you can request to be updated on the stats of users who are 
NEAR or FAR or whatever say every 10 seconds. Of course if they move when 
they are within NEAR of you then you will be automatically updated anyway).

So now you can sit and watch these shapes going by.

Other commands within a SECTOR are SEND_MAIL, JUMP_TO, 
REQUEST_SECTOR_TRANSFER etc.

Similarly to  requesting the ASPECT of users in the area, you can
request the ASPECT of PERMASPACE in the area. 

PERMASPACE is permanaent regions that default to blue. 

These will usually consist of PRIVATE PERMASPACE but some regions may 
be owned by the SC such as public database access areas and public 
bulletin boards (more on these later).

Just like CLIENTS, PERMASPACE has a default ASPECT that is a blue cube
that occupies the unit cube that is the centre of its local co-ordinate
space. Requests for higher level ASPECTS may reveal these cubes to be
buildings, flashing lights or data structures etc. 

A PRIVATE PERMASPACE ASPECT may reveal that it belongs to a friend of 
yours. (It may his name on top or maybe you recognise his style of 
castle!) 

You can move through PERMASPACE but you CANNOT stop (ie have 0 velocity) 
when in a unit cube of PERMASPACE which does not belong to you. 

So you stop one unit away (VERYCLOSE) and send a 
REQUET_TO_ENTER_PRIVATE_PERMASPACE. This is interpreted by the SC as 
a TRANSFER_SECTOR message, to the LOCAL SERVER of the user who owns 
that PP. If the request is okayed by the owner then you are sent a 
MOVE_TO message that moves you to the coords of the PP. 

Now you have transfered to a new SECTOR and are controlled by
the owner's private SC on his machine. The remote SC you were controlled
by now routes all your data straight to the LINE that that new SC is on.
(in a similar way to how your LOCAL SC is re-routing all your data
straight through to the modem).

Once again your screen is blank and you can request to see what's around
you. This person may have his SECTOR set up to look like a lounge room
or as rolling hills. All messages from users who you could see before
(ie those outside that unit cube of PP that you're in) are filtered out
to reduce bandwidth required (you may, for instance want to keep mail
coming through. If you have a powerful system you may still get all
'outside' messages but make the walls of the living room appear
transparent like smoked glass etc).

Now that you are in his SECTOR you must abide by his rules. If you send
a MOVE_TO message that will make you collide with object in his PP (eg a
chair or wall) then his sector can return okay for that request, but
when it calculates that you've hit a wall, it can send an addittional
MOVE_TO message that sets your velocity to zero. In this way you must
follow the rules he has set up in his PP. Obviously if he proves to be
obnoxious you can send a EXIT_SECTOR message that the main REMOTE SC
intercepts and so moves you back out into public cyberspace,
garuanteed.

Other users can enter the PP of your frined at the same time  so you
can have a 'private conference with only those present'. At that time
his LOCAL SC daemon has set up secondary virtual LINES to allow the
messages from several remote CLIENTS to come down the one modem
connection. As each message is preceeded by the message senders ID, it's
a fairly simply task fo rthe daemon to put the incoming messages into
the appropriate virtual LINE buffers so the SC thinks there are lots of
people/modems connected up.

Of course, the main remote SC may also provide private conference rooms where
similar duscussion can take place.

This PP may alternatively be the front end to access a commercial
database, a game service, a ticket sales office etc.

So you want to establish your own PP within the public SECTOR? You send
a REQUEST_TO_AQUIRE_PRIVATE_PERMASPACE message that is sent via the SC
to anyone who is CLOSE to you (within 10 units). If less than 50% of
those nearby say 'no' to the SC then you aquire 1 unit of PP and this is
registered in the SC's object database. You can optionally send
PERMASPACE_DATA messages to the SC that define the ASPECT of your PP to
whatever level of detail you desire so others can see your new
aquisition. Clearly, you can aquire several PP units next to each other
and build up a composite structure that is more impressive.

This aquisition is monitored by the SC and there may be limits defined.

Some reqions of PP that belong to commercial users may be large (eg a
database service for stock information may have a large area of PP that
(when you request to see higher level aspects) may be  large building
surrounded by wide grass areas with fountains and gardens). Maybe there
would be large areas within the owned PP that has no higher ASPECT so
that in a crowded area of many PPs the structure will stand out as it
has all this 'open' space around it.

You can send mail to a friend by several methods. The most straight
forward would be to use the SEND_MAIL message where you specify the
recipients ID and then the message (no set format, just specify the
length in 4 bytes). The mail will be sent straight to his LINE. If he is
currently transfered to another SECTOR, the mail is sent on to the next
SECTOR to which he travelled (he may have moved on from there too).

He may have his CLIENT software set up so mail appears as a flashing icon on
the screen or as a full letter box outside the little cottage that is
his PP.

Mail can also be send to a location and the SC will try to inform the
owner, if the mail is not received, a MAIL_FAILED message is returned.
Text mail may be appended to a PP ASPECT temporarily. In this way if
no-one is 'home' (maybe not logged in or in another SECTOR) then you can
send the mail to the PP location and when he person returns he will see
an added object on his normal PP aspect. This object may be a piece of
paper with the text message written on it.

In a similar way a true bulletin board could be set up, where people
could leave messages for others to read.

So you can conference with otheres, send mail, access commercial
services etc.

The commercial services may first connect to the system using their
original 2D flat screen interface, so when you enter their PP you just
see a single screen. In this way the interface changes would be minimal
to start with but they could develop better interfaces to make data
access more efficient. A statistics service could have a PP where data was
represented as dynamic 3D structures etc.

Probably the most useful items within the cybersapce are your AGENTS.
These items exist as packets of messages that together form an entity
that is a type of object. See the comprehensive definition later on for
details. Agents can do whatever you can do, in your place. Some agents
are simply objects that you use (for instance a 'design-an-aspect' agent
may allow you to draw items in 3D (walls, texture, motion etc) and will
then create the ASPECT data for you). It may be an access key tool (eg you
might guy a '10 shot' agent from a database service. When you want to
access that database you instruct the agent as to what you want. The
agent then goes off to the databases PP and gets a high prioirty of
service (because you paid for it!) and also knows how the database works
and so can access the data faster and then mail the data back to you (or
maybe return to you itself with its ASPECT changed to show you the data)
and after the tenth use it doesn't come back. 

The last sort of agent is independant. These actually are macro
languages that are executed by the SC and may act as guides
to newcomers or perform tasks within the sector for you (ie like a
servant). They can exist by themselves. You can have an AGENT that
'lives' in you PP and answers requests to enter from other CLIENTS while
you are tied up somewhere else. Now this brings on all sorts of
possibilities. You could send an AGENT to a conference in your place and
it may respond to text as a human would, to gather data for you. For
this reason and others, there is one strict rule, and that is that the
default ASPECT of agents are a white star made of three perpendicular
axes, no matter what.

Another example is to have several agents that travel with you in unison
and which have ASPECTS that fit into yours to make one larger, more
impressive ASPECT.

One ASPECT detail that hasn't been mentioned is sound. Obviously a sound
interface would be good (so you can talk to people you meet other than
just sending mail or typing stuf in during a private conference). Sound
would be easy enough to implement into the SEND_MAIL message protocol
(you get mail from someone who is in such and such a direction
therefore the headphones position the sound source accordingly). But I
would like to incorporate it into the ASPECT as well so you could hear
someone comming, even if you were looking in the wrong direction.

(Note: Its clear that this system is open to abuse to rogue CLIENTS that send
invalid messages. The buck will have to stop at the SERVER and so this
could end up being a pretty awesome beast as far as functionality goes.)


DETAILED DESCRIPTIONS NOT COVERED BEFORE

(incomplete section)
(note: I covered a bit more detail than planned above, hope it suffices
for now or I'll never send this thing!)
===================================================================
===================================================================
        - each CLIENT has an ID derived from their "login" address (eg internet 
        address) and so is unique. Along with ID, each CLIENT has an ASPECT 
        which describes how they appear to other CLIENTS. ASPECT by default 
        is an arrow with a single feather to indicate 3D orientation 
        ASPECT has levels, the one just stated 
        is the default level, 0. The next level is "wire frame" representation 
        that consists of a variable length list of points and vectors. They 
        have variable colour and have a DYNAMIC | STATIC parameter, if DYMNAMIC 
        is TRUE then motion paramters follow (undefined yet). The last parameter
        is EXTENDED. If EXTENDED is TRUE then a further level follows defining 
        solid geometry descriptions, which end with the EXTENDED parameter 
        for future expansion. Things are designed this way so that a simple 
        system (AT with CGA graphics) can select only the minimum display 
        criteria because that's all it can handle. Better machines '486, 
        Silicon Graphics Workstation etc can go for full solid rendering etc. 
===================================================================
===================================================================

SOFTWARE STATUS

The system so far has a CLIENT that connects to the LOCAL SERVER and
allows the user to move around within their own SECTOR, requesting 
information on and displaying PERMASPACE objects that are already in the 
SERVER's object database. This is all in wire frame (easily upgraded to solids,
but it goes too slow on the PC (386SX) for development work).

This system works on a PC and on a SUN (X11).

The graphics library used is VOGLE, but REND386 is being kept in mind
for PC stuff. An Amiga version is in the works (mainly just requires the
VOGLE driver). (VOGLE is available from most ftp sites I assume, I got
it from the Australian ftp mirror site, archie.au:/graphics/graphics/echidna)

The code is in ANSI C. This is ideal stuff for C++ but that would limit
the platforms we could easily port to (and not enough people are
comfortable with it yet).

HELP WANTED

As you can see, there are many ideas brewing here and so few
implemented. I really hope to have something significant done by the
beta release date later this year ('92) before tasks and improvements
can be farmed out to others. Ideas on modifying the concepts involved
would be wonderful, but programmers with time would be even better. Managing
remote development seems a difficult task. Breaking this into neat
packages isn't really possible at the moment. The only area that could
be done (perhaps) is the graphical operating system stuff for your
local computer. I hope people will disagree with me and show how this
can be done as a joint effort. My time for co-ordination of such an
effort is woefully limited which is why I have perservered with the
programming alone thus far.

As I think I mentioned earlier, I want to make this software freely
available with limited source distribution until it looks stable. But
in the long run, the source should be available for everyone to update
and use as they will. My main reasoning for this is to give everyone a
chance to have a working interactive system that they can connect up
together.

So far I have received about 30 requests for information/code. This
document will be posted to sci.virtual-worlds and sent to each of the
senders. If after reading this you want to help with programming, then
let me know. Any and all comments (public and email) would be 
greatly appreciated.

Cheers
        Michael Snoswell                        June 1st, 1992
        snoswell@sirius.ucs.adelaide.edu.au

p.s. okay, so the doco's not complete...(sigh)

-- 

  Michael Snoswell                         snoswell@sirius.ucs.adelaide.edu.au  
  Vision Systems Limited                   08 343 0462                          
  South Australia                          "Profound quote"