July 1997
- A simple political/social system? Jon A. Lambert
- A simple political/social system? clawrenc@cup.hp.com
- A simple political/social system? Marian Griffith
- A simple political/social system? clawrenc@cup.hp.com
- A simple political/social system? Jon A. Lambert
- Wounds and trauma Adam Wiggins
- Wounds and trauma clawrenc@cup.hp.com
- Wear Location System Jon A. Lambert
- Level abstractions clawrenc@cup.hp.com
- (fwd) Popularity of text-based MUDS clawrenc@cup.hp.com
- trying again Chris Gray
- My page, such as it is. Michael A. Hohensee
- What happened? Michael Hohensee
- Testing coder@ibm.net
- > Integrating PK Matt Chatterley
- Level abstractions / Game realism issues Matt Chatterley
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Shawn Halpenny
clawrenc@cup.hp.com wrote:
>
> In <33CFCE6E.41C67EA6@iname.com>, on 07/18/97
> at 01:22 PM, Shawn Halpenny <malachai@iname.com> said:
>
> >Yep, a slight change is necessary. Now (and again, roughly):
> >1. A client C requests object O from the database.
> >2. Add C to list of clients using O.
> >3. Return OC (a client-only copy of O) to C.
> >4. A client D (which may or may not be the same as C, but is on the
> > using-list for O) returns OC'.
> >5. If O has not changed since D's request for it (a different client
> > may have committed changes to O while D was processing), OC' is
> > atomically committed to the database, replacing O. D is removed
> > from O's using-list.
> >6. If O has changed since D's request for it, OC' is discarded and D
> > receives notification that OC' couldn't commit.
> >7. Clients in the using-list for O are asynchronously notified that
> > O has changed.
>
> Given that this basic pattern extend to all the objects which comprise
> a given event or transaction, this is identical in principle to my
> model.
It does govern all involved objects.
> Re: #3. I do some folding here, largely due to the fact that I
> haven't seperated my clients from my DB as thoroughly as you. For me,
> upon a READ request for an object X I return a reference to the
> read-only copy of that object that's already in the DB cache. If a
> transaction attempts to modify object X (remember, all it has is a
> read-only reference), then I make a writable transaction-specific copy
> (ie unique to that specific transaction) for the changes made by that
> transaction, and a seperate read-only copy of the original value of
> object X. Then, when the transaction attempts to commit, the original
> copy is compared to the current copy, and if they match, the changed
> copy is committed.
This is a sensible optimization, and one I'll likely implement, since
my objects will already do it whenever one of them is duplicated
(completely external to the DB, since the objects can have their own
copy procedures, with the DB only supplying a new object ID and a
place to put the thing). It is simple enough to move the
copy-on-write code up one level, from the objects into the DB.
> Re: #5. How do you determine that the object has changed during the
> execution of the event? I do this by always keeping an original copy
> of the object to compare to the copy current in the DB and then do a
> bit-wise comparison of the two objects. The original copy is the
> second copy made above for a modification.
>
> Aside: I'm actually getting *slightly* neater than this as the
> current plan encludes only making a copy of the object
> attribute/member which is changed, and then only comparing that at
> C&C.
Right now, my design is to just do a bitwise comparison just like
above, but I'm also thinking of something involving an object
checksum of sorts computed when an object is committed. Do your
events keep track of the attributes they touch or is that handled
entirely by the DB? Is there a problem with a situation where a
single object with attributes touched by two events within the
duration of a third event using the same object could cause some
attributes touched by the third event to falsely pass the
comparison?
> Re: #7. Similarly I post messages (flags really) to all the members
> of the interested parties lists for all the objects that a
> successfully committed transaction modified. The effect of those
> flags is that the next time those events traverse a block boundary
> (essentially any piece of code wrapped in {braces}, such as entering
> or leaving an IF, or WHILE etc), the flag gets checked and if TRUE,
> the event aborts to reschedule.
I do much the same, using the exception mechanism of the internal language.
> Concern:
>
> An event generated IO. How do you handle when it reschedules?
> Think about things like SAY, TELL, LOOK, etc for example cases.
As of yet, I don't. In the last few weeks I've been doing the "formal"
design of the base systems (network, DB, event handling). Handling
commands where events that have to touch a number of objects that have
likely changed by the time the event is processed isn't something I've
worked on yet. Therein lies the difficulty.
[ C&C based on touched attributes ]
[ large number of events contending for small number of objects resulting
in slow-motion execution of the events as they all fail/retry ]
[ solution is to split events into small, fast units, touching as few
objects as possible ]
> Going back to the case of the two rooms A and B, and the 50 players
> moving between them.
>
> If you can, split your room/motion model so that moving between
> rooms requires two events:
>
> #1 Move out of current room.
>
> #2 After sucessfully doing #1, move into new room.
>
> The question of course is "where" the player is having compleated #1,
> and processing on #2.
Indeed. What happens where an event occurs expecting Bubba to
be in a room, yet he is technically in between?
[ channel verbs are a similar case. Perhaps use a root "tell" object that
spawns events to handle I/O to each player. ]
> Note: I dug into this TELL implemenation a while back on the list,
> along with details on how to handle channels, SAY, WHISPER etc
> efficiently in this sort of event driven C&C model. If you want I'll
> try and dig it up.
If you could, thank you. At the moment, I'm thinking along the lines of
the "tell" verb posting an event for each receiving player, rather than a
root object to handle it.
> > [JCL:]
> >> Note: Events have a very short maximum time they must execute within.
> >> Event's which take longer than that time are killed and not
> >> rescheduled. This maximum time is reduced as events are rescheduled
> >> and ascend the above priority list (ie I give them more chance to get
> >> their job done, but less time to do it).
>
> >Not so for me. Am I missing something while standing here at the
> >drawing board? :)
>
> Look at it this way:
>
> 50 events are simultaneously executing on your server. Under those
> conditions a new event X (say Bubba moving from room A to room B) can
> expect to compleat in T real world clock ticks.
>
> Due to rescheduling, priority levels, or just a paucity of events,
> there are no __NO__ events executing on your server. Under those
> conditions a new event X (say Bubba moving from room A to room B) can
> expect to compleat in U real world clock ticks where U<T.
>
> Part of my attention here is that I don't want events which are
> borderline on their time values managing to C&C only because they
> throw the system into single-threaded mode and then squeak thru
> because they have the whole damn CPU to themselves.
>
> Note: A lot of this is obviated by hanging the way you measure an
> event's execution time. I originally crafted the above schema when I
> was measuring event time in real world CPU clock ticks. I have slated
> to change this to some sort of measurement of internal processing
> time, but have yet to come up with a decent system.
Can this sort of thing be remedied with smaller time units? If
events can only begin execution on the edge of a tick, you'd likely
have more contention within each tick than with smaller granularity.
--
Shawn Halpenny
"It is impossible to make anything foolproof because fools are so
ingenious." - C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling Chris Gray
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Chris Gray
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Jon A. Lambert
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Jon A. Lambert
- C&C and Event Rescheduling Jon A. Lambert
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Nathan Yospe
- C&C and Event Rescheduling Adam Wiggins
- C&C and Event Rescheduling Richard Woolcock
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Richard Woolcock
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Adam Wiggins
- C&C and Event Rescheduling Marian Griffith
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Adam Wiggins
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Miroslav Silovic
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Jon A. Lambert
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling Miroslav Silovic
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Miroslav Silovic
- C&C and Event Rescheduling Miroslav Silovic
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Miroslav Silovic
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Jon A. Lambert
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling Shawn Halpenny
- C&C and Event Rescheduling Jeff Kesselman
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Jeff Kesselman
- C&C and Event Rescheduling clawrenc@cup.hp.com
- C&C and Event Rescheduling Jeff Kesselman
- not about pk anymore Marian Griffith
- not about pk anymore Huibai
- not about pk anymore Matt Chatterley
- not about pk anymore clawrenc@cup.hp.com
- not about pk anymore Alex Oren
- not about pk anymore Matt Chatterley
- not about pk anymore clawrenc@cup.hp.com
- natural language parser (Output) Nathan Yospe
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Adam Wiggins
- Virtual Chemistry Jon A. Lambert
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Jon A. Lambert
- Virtual Chemistry Adam Wiggins
- Virtual Chemistry Jon A. Lambert
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Michael Hohensee
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Marian Griffith
- Virtual Chemistry Chris Gray
- Virtual Chemistry Marian Griffith
- Virtual Chemistry Chris Gray
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Chris Gray
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry clawrenc@cup.hp.com
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Nathan Yospe
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Nathan Yospe
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Marian Griffith
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Marian Griffith
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Jon A. Lambert
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry clawrenc@cup.hp.com
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry clawrenc@cup.hp.com
- Virtual Chemistry Marian Griffith
- Virtual Chemistry Jon A. Lambert
- Virtual Chemistry Brandon Van Every
- Virtual Chemistry Jon A. Lambert
- Virtual Chemistry Huibai
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Matt Chatterley
- Virtual Chemistry Adam Wiggins
- Virtual Chemistry Huibai
- Virtual Chemistry Marian Griffith
- Virtual Chemistry clawrenc@cup.hp.com
- Combat Adam Wiggins
- Attn JCL: A scenario for you Alex Oren
- Combat messages Marian Griffith
- Combat messages Adam Wiggins
- Combat messages Martin Keegan
- Combat messages Matt Chatterley
- What about drugs? Nathan Yospe
- What about drugs? Adam Wiggins
- What about drugs? Jon A. Lambert
- What about drugs? Martin Keegan
- coord-based recap? Huibai
- coord-based recap? clawrenc@cup.hp.com
- Docs uploaded Chris Gray
- What are the elements of playabilty? clawrenc@cup.hp.com
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Cynbe ru Taren
- META: Making the list public? coder@ibm.net
- META: Making the list public? Michael Hohensee
- META: Making the list public? Chris Gray
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Brandon Gillespie
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Michael Hohensee
- META: Making the list public? Brandon Gillespie
- META: Making the list public? Shawn Halpenny
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Shawn Halpenny
- META: Making the list public? Alex Oren
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Shawn Halpenny
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Jon A. Lambert
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Matt Chatterley
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Huibai
- META: Making the list public? Martin Keegan
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Marian Griffith
- META: Making the list public? Jon A. Lambert
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Shawn Halpenny
- META: Making the list public? clawrenc@cup.hp.com
- META: Making the list public? Matt Chatterley
- Longbows and such. Cynbe ru Taren
- R-trees &kin Cynbe ru Taren
- R-trees &kin Martin Keegan
- META: Making the list public? S001GMU@nova.wright.edu
- META: Making the list public? clawrenc@cup.hp.com
- META: C&C and Event Rescheduling clawrenc@cup.hp.com
- Source data on Crossbows clawrenc@cup.hp.com
- Source data on Crossbow Cynbe ru Taren
- Source data on Crossbow Matt Chatterley
- Source data on Crossbow Cynbe ru Taren
- Source data on Crossbow Matt Chatterley
- Source data on Crossbow clawrenc@cup.hp.com
- Source data on Crossbow Matt Chatterley
- Source data on Crossbow clawrenc@cup.hp.com
- Source data on Crossbow Matt Chatterley
- Source data on Crossbow Caliban Tiresias Darklock
- Source data on Crossbow Marian Griffith
- Source data on Crossbow clawrenc@cup.hp.com
- Source data on Crossbow Orion Henry
- Source data on Crossbow Cynbe ru Taren
- Source data on Crossbow Matt Chatterley
- Source data on Crossbow Michael Hohensee
- Source data on Crossbow Matt Chatterley
- Source data on Crossbow clawrenc@cup.hp.com
- Source data on Crossbow daggers@iquest.net
- Source data on Crossbow Rudy Neeser
- Source data on Crossbow Malcolm Tester II
- Source data on Crossbow Travis Casey
- Source data on Crossbow rayzam
- Source data on Crossbow Blane Bramble
- Source data on Crossbow Daniel Carruth
- Source data on Crossbow Michael Tresca
- Source data on Crossbow Bobby Martin
- Source data on Crossbow Christopher Kohnert
- Source data on Crossbow Bobby Martin
- Source data on Crossbow Christopher Kohnert
- Source data on Crossbow Dave Rickey
- Source data on Crossbow werda555@yahoo.com
- Source data on Crossbow Nathan Yospe
- Source data on Crossbow Travis Casey
- Source data on Crossbow Bobby Martin
- Source data on Crossbow Hans-Henrik Staerfeldt
- Source data on Crossbow Bobby Martin
- Source data on Crossbow Ben Tolputt
- Source data on Crossbow andy.wharton@ascentialsoftware.com
- Source data on Crossbow Skaei@aol.com
- Source data on Crossbow rayzam
- Public Archives (META: Making the list public?) Brandon Gillespie
- Socrates - A brief look at AI(?) Jon A. Lambert
- Evil coders from beyond the grave Matt Chatterley
- Evil coders from beyond the grave Orion Henry
- Evil coders from beyond the grave Matt Chatterley
- Evil coders from beyond the grave Chris Gray
- Evil coders from beyond the grave Matt Chatterley
- Evil coders from beyond the grave Adam Wiggins
- Evil coders from beyond the grave Matt Chatterley
- Graphical MUDs Michael Hohensee
- Graphical MUDs Cynbe ru Taren
- Graphical MUDs Michael Hohensee
- Graphical MUDs Shawn Halpenny
- Graphical MUDs clawrenc@cup.hp.com
- Graphical MUDs Chris Gray
- Brief bio Niklas Elmqvist
- Brief bio Martin Keegan
- Multi-threaded programming under Linux Greg Munt
- Multi-threaded programming under Linux Nathan Yospe
- Multi-threaded programming under Linux Cynbe ru Taren
- Multi-threaded programming under Linux S001GMU@nova.wright.edu
- Multi-threaded programming under Linux Chris Gray
- Multi-threaded programming under Linux Jeff Kesselman
- Multi-threaded programming under Linux Cynbe ru Taren
- Multi-threaded programming under Linux Orion Henry
- Multi-threaded programming under Linux Michael Hohensee
- Multi-threaded programming under Linux] Michael Hohensee
- Multi-threaded programming under Linux clawrenc@cup.hp.com
- Multi-threaded programming under Linux Jon A. Lambert
- Multi-threaded programming under Linux Nathan Yospe
- Multi-threaded programming under Linux Jon A. Lambert
- Multi-threaded programming under Linux Alex Oren
- Multi-threaded programming under Linux clawrenc@cup.hp.com
- Multi-threaded programming under Linux clawrenc@cup.hp.com
- (fwd) LP: How does it work? coder@ibm.net
- Collision detection coder@ibm.net
- OT: Multi-threaded programming under Linux coder@ibm.net
- Motivating people Greg Munt
- Motivating people Chris Gray
- Motivating people Huibai
- Motivating people clawrenc@cup.hp.com
- Motivating people Jon A. Lambert
- Motivating people Greg Munt
- Motivating people clawrenc@cup.hp.com
- Motivating people clawrenc@cup.hp.com
- OT: Multi-threaded programming under linux Orion Henry
- Graphic MUDS. Jeff Kesselman
- Graphic MUDS. Chris Gray
- Graphic MUDS. Jeff Kesselman
- Graphic MUDS. Chris Gray
- Graphic MUDS. Matt Chatterley
- Graphic MUDS. Adam Wiggins
- Graphic MUDS. Chris Gray
- Graphic MUDS. Michael Hohensee
- Graphic MUDS. Jon A. Lambert
- Graphic MUDS. clawrenc@cup.hp.com
- Graphic MUDS. Adam Wiggins
- Graphic MUDS. Martin Keegan
- Graphic MUDS. Adam Wiggins
- Graphic MUDS. clawrenc@cup.hp.com
- Graphic MUDS. Martin Keegan
- Graphic MUDS. Matt Chatterley
- Graphic MUDS. Jeff Kesselman
- Graphic MUDS. clawrenc@cup.hp.com
- Stories? Marian Griffith
- KaVir Nathaniel Blundell
- OT: Server Web Site Jon A. Lambert
- Recent mail delivery problems... clawrenc@cup.hp.com
- Mail not getting to the list coder@ibm.net
- Mail not getting to the list Caliban Tiresias Darklock
- Mail not getting to the list Jeff Kesselman
- Graphic MUDS/Ultima Online Koster, Raph
- Graphic MUDS/Ultima Online Adam Wiggins
- Graphic MUDS/Ultima Online Koster, Raph
- Graphic MUDS/Ultima Online Jeff Kesselman
- Graphic MUDS/Ultima Online Adam Wiggins
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online Koster, Raph
- Graphic MUDS/Ultima Online Jeff Kesselman
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online Adam Wiggins
- Graphic MUDS/Ultima Online Alex Oren
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Koster, Raph
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Chris Gray
- Graphic MUDS/Ultima Online Richard Woolcock
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online Chris Gray
- Graphic MUDS/Ultima Online Jeff Kesselman
- Graphic MUDS/Ultima Online Nathan Yospe
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online Richard Woolcock
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online Jeff Kesselman
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online Richard Woolcock
- Graphic MUDS/Ultima Online Nathan Yospe
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Richard Woolcock
- Graphic MUDS/Ultima Online Nathan Yospe
- Graphic MUDS/Ultima Online Adam Wiggins
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online Koster, Raph
- Graphic MUDS/Ultima Online Jeff Kesselman
- Graphic MUDS/Ultima Online Michael Hohensee
- Graphic MUDS/Ultima Online Adam Wiggins
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Matt Chatterley
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online Jeff Kesselman
- Graphic MUDS/Ultima Online Adam Wiggins
- Graphic MUDS/Ultima Online Jeff Kesselman
- Graphic MUDS/Ultima Online Adam Wiggins
- Graphic MUDS/Ultima Online Jeff Kesselman
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- Graphic MUDS/Ultima Online clawrenc@cup.hp.com
- First Muds - newbie magic? Nathan Yospe
- First Muds - newbie magic? clawrenc@cup.hp.com
- First Muds - newbie magic? Martin Keegan
- Dynamic Descriptions Nathan Yospe
- Dynamic Descriptions Chris Gray
- Dynamic Descriptions Martin Keegan
- Dynamic Descriptions clawrenc@cup.hp.com
- Dynamic Descriptions Nathan Yospe
- Dynamic Descriptions Jeff Kesselman
- Dynamic Descriptions clawrenc@cup.hp.com
- Dynamic Descriptions Jeff Kesselman
- Persistant worlds, Dan Huibai
- Worlds VS Games, etc {was GMuds, UO} Nathan Yospe
- Worlds VS Games, etc {was GMuds, UO} Koster, Raph
- OT: NIS/AlterNIC and the DNS system Caliban Tiresias Darklock
- OT: Mail not getting to the list clawrenc@cup.hp.com
- OT: Mail not getting to the list clawrenc@cup.hp.com
- Persistance/stability Chris Gray
- Persistance/stability Miroslav Silovic
- Persistance/stability Matt Chatterley
- Persistance/stability clawrenc@cup.hp.com
- Persistance/stability Chris Gray
- Persistance/stability Brandon Gillespie
- Persistance/stability Adam Wiggins
- Persistance/stability Chris Gray
- Persistance/stability Adam Wiggins
- Tilting at the SimWindmill - was UO Jon A. Lambert
- DESIGN: The purpose of MUDding? coder@ibm.net
- DESIGN: The purpose of MUDding? Brandon Van Every
- DESIGN: The purpose of MUDding? Matt Chatterley
- DESIGN: The purpose of MUDding? Brandon Van Every
- DESIGN: The purpose of MUDding? Matt Chatterley
- DESIGN: The purpose of MUDding? clawrenc@cup.hp.com
- DESIGN: The purpose of MUDding? Matt Chatterley
- DESIGN: The purpose of MUDding? Jeff Kesselman
- DESIGN: The purpose of MUDding? Jeff Kesselman
- DESIGN: The purpose of MUDding? clawrenc@cup.hp.com
- DESIGN: The purpose of MUDding? clawrenc@cup.hp.com
- DESIGN: The purpose of MUDding? clawrenc@cup.hp.com