From carlosj@cc.gatech.edu Fri Apr 2 11:08:06 1999
Date: Fri, 2 Apr 1999 01:10:47 -0500 (EST)
From: Carlos Jensen
To: elc@cc.gatech.edu
Subject: [elc-grad] Tuesdays ELC assignment
Ok, here is your assignment for this Tuesday. You'll be happy to know that
I'm not going to make you read anything but this email, no software to
test, you just have to do some thinking, and hopefully some up with some
good ideas and suggestions. Those of you involved in AquaMOO should see a
lot of overlap in areas, and I'd appreciate hearing your own solutions.
So, my project is to redesign MediaMOO. You should all have a fair idea
what MediaMOO is, so I wont bore you with the background material. This
project is really composed of two separate components; that of
re-designing the MOO itself, and that of developing a new MUD platform.
The first part is fairly straightforward (he said innocently). MediaMOO is
fairly dead these days. The current theory is that there was a massive
influx of people in the early days, most of which were already established
researchers in the field. As they all became familiar with MOO's, online
communities and the internet in general, they went on to form their own
MOO's etc, and left MediaMOO. MediaMOO served a purpose to them at that
phase of their lives, but they had earned their wings, and as there was no
steady influx of people, the MOO died away.
Our feeling is that the concept behind MediaMOO (to provide people in this
field a forum for informal socialization and networking) is still a good
one, but that our population model needs to change in order to make
MediaMOO a stable community. The idea is that it is a lot easier to
provide a useful service to people going through a particular phase of
their lives than it is to provide to a group of people for their entire
lives. So, Amy Jo Kim suggested that we might want to aim MediaMOO more
towards graduate students. We're new to this field, getting involved in
research, in need of making contacts and building a professional network.
Grad students could benefit by being able to find and keep in contact with
others specializing in the same thing as they are, or doing related
research at other universities. Much of our research here is so
specialized that there are typically only a small handful of 'experts'
within our own departments. Imagine being able to easily find out who is
doing what within the study of online identity, deviance or 3D MUD's.
Being able to meet with them on a regular basis and compare notes or share
resources could be a tremendous resource during your studies, as well as
later job-hunting opportunities. This is after all what we go to
conferences to do, so why not online?
So, the question to you is; Is this a flawed concept? Are we missing
something, or is this a good idea? What would make you join a community
like this, or just as interestingly, why wouldn't you? Are there any
lessons from other online communities that you think are particularly
relevant to the new MediaMOO, and which we should keep in mind? What
would help make this place more 'graduate student oriented,' and what does
this concept mean to you?
So, on to the second part of the project (and the more important one):
We are doing some major technological changes to MediaMOO, but most of
them are encapsulated in the second part of the project, building a
distributed, interconnected, media-enabled software platform for online
communities (buzz-word section over). What this means is that anyone who
uses our software will be able to make worlds using any form of media
(text, 2d graphics, 3d graphics, whatever as long as he writes the client
to support it), that these separate worlds will have the ability to link
and exchange people and objects transparently (ei. You will be able to
walk from one world to the other by following an exit, and you can take
your character and your objects with you wherever you go) and that the
worlds themselves will be build on a massively scalable distributed
architecture instead of the monolithic MUD model. The distributed
architecture allows the world to spread the load over many smaller
machines, and to subdivide a world into sub-domains for administrative
purposes (the ability to have wizards over only parts of the world etc.)
More importantly, it allows us to let the user keep all his own stuff on
his own machine, and not burden the central servers with junk. Oh, and
just to top it all off, the server will be disk based. This means that
unlike MOO, we wont keep the whole world in memory all the time, just the
parts that are relevant or being used at the time.
So, how does all this work? Dunno yet The media part is fairly
straightforward. Today's MUDs really don't care what they are serving you,
to them its just a chunk of bits anyway, so it could just as easily be a
3D model, or a jpeg. The real task here is to allow for different types of
networking to ensure that different types of content gets different
priorities. You might be willing to wait while the description of the room
loads, as long as the conversation is still coming across, but you'd never
accept the reverse situation. We need this system to be disk based if we
are going to allow for rich media. MUD's are bloated as is with only
textual descriptions. There will be a performance hit because of this, as
we have to load new rooms from disk, but I believe that this can be
performed in an acceptable fashion with smart caching algorithms. For
MediaMOO, we are going to go with a "webby" environment, and text dialog.
I think it is the best medium for the kind of community we are trying to
build, and I would love to hear counter arguments if anyone has them.
The interconnected part of this is largely an extension of the distributed
architecture (which is largely a big black box at this moment). Servers
are aware of each other to a limited sense, and able to find each other on
the network. They will be able to pass objects to each other just like
nodes inside the distributed network do. The only difference is that these
objects are subject to more significant security restrictions and checks.
So why are we making this platform so MUD like? Well, MUD's are supersets
of a lot of the different online community platforms that we see today.
Mail and news is integrated in MUD. You have a persona, but without it,
you have straight IRC. If you remove the persona and the synchronous
communication, you have a web server (or any other server that is more or
less static, serving up information on request).
So, apart from making new and exciting MUD's, what could this be used for?
Well, good questions, and I'd love to hear from you on your ideas. Some
ideas that we've gotten are to support online learning, by enhancing
things like the Classroom 2000. This platform as I mentioned will be a
superset of a web server, so anything you can do on the web, you should be
able to do using our system. So why don't you wrap a web site such as the
Classroom 2000 site in our service and add to it the ability for its users
to become aware of each others presence, and allow them to communicate and
collaborate synchronously. The same could be used for online sales (how
many of you bother to contact web sites for pre-sales information if they
only give you an email address), customer service and similar
applications. The transition from having a simple web-site to using a
service such as this would not be very costly, as the content use would be
the same (though the client would differ).
Of course, this architecture will be able to support a more varied set of
applications than traditional MUD's, and handle a lot higher loads. So, to
summarize, the goal of this project is to invent internet-2. (just
kidding).
So, what do you guys think? Does this sound interesting, if so why / why
not? I didn't get to go into a lot of detail because this email is already
incredibly long, but feel free to ask me anything, and we'll see if I know
the answer.
Think about these issues for Tuesday related to this part of the project:
Is this interesting? Do you think that this could work (or more
importantly, why wont this work?) Are we walking into a trap here, are we
overlooking any important or fundamental problems here? What do you think
we need to pay particular attention to in the design and implementation of
this? What should we be careful to avoid? What is your cool idea for how
to do this?
I appreciate you all taking the time to read this, and I appreciate the
chance to get feedback and comments from you all, I think this will be
very valuable. If you have any questions or comments before the meeting
feel free to talk to me or email me at will.
Thank you, Carlos
-Carlos Jensen (carlosj@cc.gatech.edu)
College of Computing
Georgia Institute of Technology
Atlanta, GA 30332-0280
FAX: 404-894-9846
From carlosj@cc.gatech.edu Fri Apr 2 11:08:12 1999
Date: Fri, 2 Apr 1999 01:46:51 -0500 (EST)
From: Carlos Jensen
To: elc@cc.gatech.edu
Subject: [elc-grad] adentum...
Sorry to burden you wit even more stuff, but this bit is rather important.
MUD's traditionally are interactive databases, whereas I'm thinking of
building this on the idea of a virtual machine. The advantages of the
database is that it is very efficient in terms of memory and storage
because nothing is duplicated, only referenced. The virtual machine on the
otherhand means that every object needs to be instantiated, which means a
lot of memory overhead. On the other hand, databases are relatively
monolythic in nature, something which I'm trying to stay away from.
Virtual machines seem to be more inclined towards this idea, to the point
where every "room" could be given control of the connections of its
inhabitants amd handle all communication locally. I also have an intuition
that this model will be a lot more functional for the more advanced uses
of this platform, but no clear answers.
So, Database or virtual machine? Why? Or do you have a third alternative?
-Carlos Jensen (carlosj@cc.gatech.edu)
College of Computing
Georgia Institute of Technology
Atlanta, GA 30332-0280
FAX: 404-894-9846