Random thoughts

[Jon A. Lambert]

This seems to be mail I sent to CL some time ago.  Let me clarify
where we seemed to going with this.  He probably reposted it with
the intent of continuing(?). 

> From: Jon A. Lambert <jlsysinc at ix.netcom.com>
> Date: Saturday, January 25, 1997 5:42 AM
> 
> Aye, I have been playing with ColdX/Genesis for the last 2 weeks so
> this concept is clear to me now.  I've got it running on Linux and have
> the compiler running on Win95.  I am very close to having the driver
> running on Win95 :-)

I went ahead and completed the port.  Brandon Gillespie has made
the source and binaries available at <www.cold.org>.  I doubt there's
much interest here, since we are writing our own little messes. ;-)
My impression of this server, Genesis, is pretty good.  It is a very stable
piece of code and the nice feature which attracted my attention was its
persistent objects and object caching.  The database is however based 
on NDBM which is somewhat archaic, low-level, and does not have good
recovery mechanisms.

> My first impression of ColdC is much better than LPC.  ColdC seems to be
> more austere than LPC but just as powerful.

Further impressions of ColdC led me to believe that this wasn't quite what
I was looking for in a language.  The inheritance structure has some
peculiarities and quirks that are not obvious to the new user and can be
frustrating to a C++ person like myself.  The people involved are a rather
nice and talkative group of fellows.  They happily answered most of my
inane questions and comments on ColdC.  They were pretty open minded
on language extensions and have what amounts to "attribute overloading" 
in the works.  The ColdC language does have good documentation 
and makes powerful uses of regular expressions.
  
The ColdX core was however another matter.  It is very poorly documented
and appeared to me very complex and convoluted.  I don't want to diminish it, 
for it is an alpha work that is 3 years in progress and to those involved its design 
it is probably crystal clear.  It does have some exciting features like HTML 1.0
support and a hyper-text help and database viewing system that can be 
accessed from a web browser.  Brandon swears he has lots of paper 
documentation on the core and will eventually get around to publishing it.

> I am not sure how all this relates to my in-progress server since the concepts are
> quite different.  My server has a decidely DIKU bent .  I am toying with the idea
> of attempting to program some of my existing servers' objects into ColdC.
> The online programming seems quite awkward to me right now.

Let me clarify what I mean by DIKU bent.  I am writing a game server not
a generic programming environment server like LP or Genesis.
The game's configuration and objects reside in a disk database and these 
objects are not extended via the servers language, they are only manipulated
by the server language.  It is my opinion that complex languages like
C, C++, Java, LPC and Cold are too difficult to learn by my builders which
tend to be strictly non-programmers although very creative and smart people.
My building programs will be GUI editors with nice point and click interfaces
and the language used by them will be minimal and integrated into the
building interface.  This will probably end up resembling a Visual Basic IDE
environment (*giggle*).  Controls which represent "black box" C++ programs 
can be happily dragged about and attached to objects, rooms and NPCs.
They will have properties boxes for minimal tailoring.  I wasn't kidding about
the Visual Mud++ with ActiveMud controls concepts!  Lets just hope
Microsoft doesn't get wind of it, so shhhh!.  Currently my proposed minimal 
language seems to closely resemble a subset of Fortran with very weak typing 
though this was not my original intention.  Wait, on second thought this might
be Rexx.  

> 
> > 
> > How does this handle the Dragon's Dinner scenario, ala:
> > 
> >   Transaction A checks value X (read, no write, thus no lock), and on that
> >   basis, changes object Q to state Q`.
> > 
> >   Meanwhile, transaction B modifies value X to state X`, and commits prior
> >   to A committing.
> > 
> >   Problem: Logically Q` and X` can't exist at the same time (eg the door is
> >   closed, _and_ there is a wind blowing through it).
> > 
> > It would seem without some checking of read-locks that its a gaping hole.
> > 
> Yes Autocommit is useless to your scenario.  Although relational
> technology does handle this scenario quite well.  In the commercial
> environment read/locks are avoided like the plague.  I've worked on a
> number of inventory systems where your 'dragon dinner' scenario can
> and does occur.  It is generally a risk assesment vs performance issue.
> Read/locks are really bad if you come upon a wait condition ( ala user
> input).  The other conditon that comes up frequently is in locking multiple
> objects.  If you come across an object that is locked by another 
> transaction you must, in most circumstances, release all your locks
> and start over or cancel.  Otherwise deadlocks can and will occur
> between transactions that need to get at 2 or more objects in common.
> 
> Now in this particular example, read/locks should work.
> 
> 1) dragon and player both attempt to read/lock exit/door object.  
> 2) first one to the lock wins.
> 3) If the dragon wins, he releases his lock after he has
>    traversed the door.
> 4) If the player wins he releases the lock after the door is slammed.
> 
> I would guess if the dragon wins, the player still completes the door
> closing?  Or you could fail the door slam request based on the failure to
> get a lock?  If you fail the door slam, do you retry?  It would have side 
> affects for multiple characters attempting to walk through doors at the
> same time. 
> 
Yikes! This scenario may involve two separate issues.  On one level
it represents maintaining proper object consistency in a multithreaded
environment.  And on another level, which I was alluding to is 
implementing it within the locking mechanisms of a relational database
like Oracle, DB2, MSQL or Watcom SQL (my currently used DB).
Its probably a good idea to restart this discussion with some clearer
distinctions between thread locking and database locking.
I am currently pursuing a model which includes an Object Manager
subsystem.  The Object Manager exposes the objects to the rest
of the server subsystems and provides the object locking, object caching,
and disk database access.  Care to give it this scenario another go round 
Chris or anyone for that matter?


JL