[MUD-Dev] Gamora: Lessons learned? (fwd)

[Niklas Elmqvist]

As suggested by Bruce Michener (though in more general terms), I got in
touch with Scott Miller, one of the people behind Gamora, and asked him
about the Gamora teams' experiences and words of wisdom (I chose Gamora
because it most closely followed my own thoughts about DevMUD, including a
heavy OO-emphasis...). Scott permitted me to post his replies to the list,
so I will follow up this post with his second reply. 

In the first message, I was kind of badly informed about Gamora and had no
real idea what to ask about. You'll see much more concrete and less vague
questions and answers in the next post.

I will hunt for other people to ask these kinds of questions, but it would
of course be nice if other list members could help me out...

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "The trouble with being a god is that you've got no one to 
   pray to."
		-- Terry Pratchett, Small Gods

---------- Forwarded message ----------
Date: Mon, 26 Oct 1998 18:04:24 -0500 (EST)
From: Scott Miller <scgmille at indiana.edu>
To: Niklas Elmqvist <d97elm at dtek.chalmers.se>
Subject: Re: Gamora: Lessons learned?

> Now, I realize that you have no interest/knowledge in MUD development, but
> you (and the rest of the Gamora team) *do* have considerable experience in
> general server design. We want to investigate other similar projects
> before boxing ourselves in. In other words, we need to sample the state of
> the art to not make any stupid mistakes :)
Always a good thing. ;)

> (pointers to good documentation are also welcome, but Gamora seemed at
> best to be sparsely documented).
You're being nice.  Actually, there is a sub project documenting Gamora as
we speak.  The website is http://staff.netg.se/~quest/gamora_doc.html.

> 1. What are important features and key abstractions of a server
> 	architecture, judging from your experience with Gamora?

Assuming you want full abstraction over a number of protocols, you can
fracture the system into three components, first, the physical socket,
which may be TCPIP, UDP, etc.  Second, the code that interfaces with that
socket to return meaningful data types, and third, the code that deals
with that data.  Thats what has been done when using Gamora for networked
applications.  

> 2. Why did you design Gamora the way you did? What were the alternatives
> 	at the time, and why did you discard them?
Gamora was written for flexibility, originally in server applications, but
the idea that Gamora could be used elsewhere was a nice surprise.  The 
architecture was designed to identify places where abstraction was most
useful, and then how to make coding with this abstraction very easy.  I
personally don't know of any alternatives at the time.  The closest
thing to Gamora are standard communications libraries.  Gamora takes
a different approach, instead of libraries, Gamora puts a physical
program (the architecture) underneath the code, so coding doesn't have to
involve the plumbing of connecting bits of a library together.

> What mistakes did you make? 
I think the biggest mistake was focusing on making Gamora a server
builder.  If I had realized the potential beyond this earlier on, I
wouldn't have had to go back and correct some assumptions I had made about
the architecture.  But all in all, no serious design flaws have set us
back.
 
> 4. What were the good things?
There are lots of good things, and I won't go into them in this document.
Gamora turned out to be really flexible without being so elegant that
its difficult to code for.  I'm surprised every day at some new ideas
people have using Gamora.  I'd suggest you read the docs when they
come out, they'll likely be more enlightening than me.

> 5. Do you have any general words of wisdom when working in this problem
> 	domain? Anything that you can boil down as the "essence of making
> 	Gamora?"
There's a balance between abstracting too much and tying ideas that should
be abstracted.  The only wise saying I have is watch where you draw that
line.  It can make the difference between a lot of flexibility, and a lot
of programming.

> Any other information is of course welcome. We are grateful for any help
> we can get.
Well, not sure how helpful this was.  It was all very vague, but I think
when you read the docs much more will become clear. 

	Scott
	
--------------------------------------------------------------------------
 Java Programmer          Scott Gregory Miller          Linux afficionado
 Graphics Designer        scgmille at indiana.edu              General Loony
--------------------------------------------------------------------------