MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: MOO and VRML 2.0 ?

Well, its nice to see this discussion start.

I think MOO is good for a number of different purposes. I think that we
should accept that there is not going to be, any longer a single overriding
theme to MOO, it is coming of age. And its a WONDERFUL idea for a number of
different reasons.

Personally I say go to it, build them all, and experiment with them.

The roles I see for MOO are a little bit different that some of the
ones you guys are talking about.

The DIS system with distributed Objects is of course the only way to
do realtime animation over a network. Anticipatory sending of timestamped
data, is a real godsend for realtime animation. But it requires a common
Client Architecture. DIS had its own, obviously. But in the REAL live
WORLD WIDE internet, no one client is going to corner the market.

Too many platforms too many variations. We need a standard, and VRML
is only the first step, to a DIS like utility.

With the start of interest in MOO-MOO communications, and WWW server/client
emulation, begins the ability to mask the nature of the net within the
application. Who cares how the network gets the job done, if you press
the button and the picture appears.

That is the value of Netscape. You push the button, and the screen
changes.... Its a bit slow and quirky, but the concept is valid.

Problem is, Netscape is a single line communications device, it doesn't
telnet in, and run Netscape at the same time. We need the ability to 
share at least two different channels on the same client. One for WOO
and one for interaction with the MOO. Or we need to build the client
server relationship so that it can drop the channel and still be able
to send packets from time to time to interact. A special MOO/WOO message
interpreter between client and MOO.

So suppose we get the client to work....

Suppose we get the VRML, Animation Files, TEXT files all to be
available interactively.....

We have a wonderful toy, it might be good for certain types of communication
education and so on, but it's too glitzy for real work.

And that my freinds is why I think we need a Modular Core, one that can
be BOTH the fancy VRML, ANIMATION game, and a pure text interface
VR or not as required.

It's not too long now before people are going to be demanding the same
level of sophistication on the Internet as they get at home in Windows
or MAC. They are going to want, resident programs for spelling, and
translation, and who all knows what.

I think, if the language ever gets cleaned up MOO is a natural for such
tasks, Set up a MOO Server JUST for SPELLING, and send messages to it
say, articles to be spell checked automatically. No one knows its a moo
but the person running it, signs on, and reads his stats from the VR
interface.

Besides, I know its not ADA or C++ but the database concept sure makes
it easier to maintain.

Some situations are going to be, intermediates between the Program that
is an environment when it is being maintained, and the Environment that
is running in real time. Somwhere there have to be directories, routers
or whatever, that help people find the information their looking for.

What better way, then letting the user, give a Bot, the search string and 
send it off for a random walk until it gets an answer from one of the
search engines. Registered as objects on the MOO. Where better than on a MOO 
like environment where the bot can insert the search string into each 
engine and if it gets a negative answer go on to the next database.

For exhaustive searches, set up a fleet of bots to do a search across
the whole list. Each one bringing back its own version of the answers
and reading it into a special database client that builds the definitive
listing. The list search limited mostly by the MOO's usage limitations
programmed in by the OWNER. (It just takes longer to get a result, instead
of jamming everybody elses machines up.)

The limitations are more, in what we allow ourselves to do, than in
any builtin limitation of the Server.

				Grey

GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca
2536 138A ave Edmonton
References:
Home | Subject Index | Thread Index