1) Use M**s as a server to dynamically create VRML scenes.
2) Use my favorite M** <tm> for the server.
3) Define a generic object for all servers to handle.
4) Perhaps XXX is a better alternative.
My personal views on each are:
--- 1) Use M**s as a server to dynamically create VRML scenes ---
Beautiful idea, why didn't I think of it? ;)
--- 2) Use my favorite M** <tm> for the server ---
It has taken all of my personal reserve to refrain from commenting on ANY
of the M**s put forth in this forum. I will say that we should NOT instantly
restrict ourselves by focusing on any single driver, since such an action
really is not needed. (more later in this message)
--- 3) Define a generic object for all servers to handle ---
Bad move if I am reading this correctly. Defining a generic object which
every M** system could interpret to its own database may be feasable, and
may be nifty, but it is not necessarily what we want. It would involve
a large amount of development for something which would be handy, but
nearly irrelevant.
Then again, I could have totally mis-understood the post.
--- 4) Perhaps XXX is a better alternative ---
Actually, this is really referring to the pointer to Intermud. I would
be against tying this to Intermud because although it is a good effort,
from what I have seen (being involved with the list), it is primarily
centralized on LP muds, and the designs ignore existing protocols (creating
re-implementations of them instead).
-----------------------------------------------------
I believe the direction we must take is to define a protocol which is used
in connecting to a virtual environment system (sorry, best name I can think
of). I have been playing with the designs for a protocol of this calliber
for a while now. I have considered MANY designs (including many implemented
at existing M**s, RipScript and HTML). My own personal opinion is that
it should be kept simple, and it can be easilly done by slightly changing
how HTML documents/objects are handled (since you would be working with a
constant stream rather than a single request).
Once a protocol of this level is implemented, it does not matter which
platform you use, the clients should be able to connect to them all. Rather
than spamming this entire list I have collected my notes and created the
document:
http://www.declab.usu.edu:8080/vrml-protocol.html
As far as the server aspect goes, I have been working on the database of a
virtual environment system from the base level up for over a year, with
the intent of integrating VRML into the entire system. I have spoken on the
list before on this vein, I am in the process of documenting what I have done
to this point, as well as what I will do. I will post the URL when I am
finished. Until now, I would like to note that I do not personally feel
that jumping onto the MOO bandwagon is the best idea. MOO was a great step
in the right direction, but does it not disillusion anybody with the fact
that even the creator of MOO says there are better designed systems
available?
(oh, and I almost forgot, some people have requested information on ColdX,
you can find it via: http://www.declab.usu.edu:8080/ColdX/)
/\ Brandon Gillespie (http://www.declab.usu.edu:8080/~brandon/) /\
|| "They who dream by day are cognizant of many things which escape ||
\/ those who dream only by night." - Edgar Allan Poe \/