Greetings. :)

[clawrenc at xsvr1.cup.hp.com]

In <199704070037.AAA637170 at out2.ibm.net>, on 04/06/97 
   at 10:32 AM, Nathan Yospe <yospe at hawaii.edu> said:
>On Sun, 6 Apr 1997 coder at ibm.net wrote:
>:On 01/04/97 at 09:47 AM, Michael Hohensee <michael at sparta.mainstream.net>
>:said: >On Mon, 31 Mar 1997 claw at null.net wrote:

>:>> Hehn.  I actually make no distinction among players, mobiles, rooms,
>:>> objects, utility objects, etc.  There are just no unique object types. 
>:>> They're all the same to the server.
>:>
>:>Doesn't that waste memory?  
>:
>:No really.  I don't run in memory.  I run off a heavily cached disk-based
>:DB, so there is no in-memory class structure.  

>I think we're hitting upon a fundamental philosophical difference
>between the server approach and the codebase approach. 

Agreed.  As you comment later, we're using remarkably similar design
principles for what are on the face of it very different approaches.

>I've noticed
>that my internal language is resulting in my system, in some
>respects, drifting more and more toward what you describe, to the
>point that, if I yanked every existing object, I might have a crude
>and clunky version of your server (with a seriously different sort of
>threading and event scoping... the event thread imbedment in layered
>containment is a bit lower level than my descriptions, but the
>descriptions reflect my use of them, not their potential
>application.) 

Precisely.  I suspect that once you get down to the sort of threaded
interactive, self-generating event driven systems (and various other
picks of multisyllabic adjectives) that we are talking about, that
they're all going to look pretty much the same.

Its either that, or I've just brainwahsed you all into thinking my
way.

>Nevertheless, I decided to, rather than deal with
>writing a caching/disk swapping system, rely instead on the OS
>swapping, and on discrete object referencing. 

I've debated on this one and decided not to.  Base reasons:  My
objects are considerably smaller than the OS'es basic page size (not
dealing with OS'es with variable page size support).  There is no
reasonably discernable or predictable pattern or spread to the
distribution of the objects in the working set of any given event, and
it can reasonably be assumed that the general case would have every
object resident on a unique page (ignoring page boundary questions). 
Given my multi-threaded approach to event handling (ie lots
simultaneously executing events) the working set for the entire server
at any instant is likely to be large.  

Cross all the above together, and you end up with a positive feedback
loop on the total working set of the server.  Its actively unstable. 
The native tendency is going to be for the server to blow the working
set of pages out to Hades and gone.

I just don't wnat to be there to see it page thrash.

Sooooooo, I do my own DB manipulation and return references instead of
copies everywhere I can (loosely I return a reference which the first
write turns into a copy) to try and minimise the in-memory working set
sIze.  The cache sitting on top of that of course works the other way,
keeping the working set fairly large, but that at least can be tuned
without affecting the physical processes of the server.

>This mainly follows the
>expectation that, while there is potential for the creation of new
>objects, they will not actually _be_ created in large quantities...

Ahh.  If you look at my implementation of spoof and watchers (they
each create transient objects), plus the free user programming side,
I've got the worst of both worlds:

  High frequency creation and deletion of objects (raising recycling
Q's).
  
  Actively fluid inheritance tree.

>:Part of the key here is that my server actually knows nothing about the
>:game it is representing, or in fact anything about any games at all. 
>:Truth to tell, my server has no concept that it has anything to do with
>:games at all (that was one of the design criteria).  What the server does
>:know about is its databse, how to submit queries to that database, and
>:that's pretty well all it knows.  Everything else, all the game stuff, the
>:command parsing etc happens as code written inside of database records.

>This code would be what, interpreted, partial (bytecode) compile,
>partial (bundled pointer) compile, or full (dynaloaded) compiled?

Bytecoded with a lot of native routines (a lot more than ColdC).

>:This is probably better understood from the inside oot, rather than trying
>:to look at the server side:

>:  Everything is an object.
>:  Objects are defined in a database.
>:  Objects have Unique IDs.
>:  Objects may contain methods, attributes and verb templates.
>:  Objects may inherit from other objects (multiple inheritance).
>:  Methods may call other methods during their execution.
>:  Everything that happens is part of an event.
>:  An event is a grouped set of state-changes which occurs to the DB 
>:    atomically as of a known time.
>:  An event may log future events.  (ie A method, should its event 
>:    succeed, may log future events)

>What exactly do your states look like, if you don't mind answering?

What are you defining as a "state"?  The external state of an object? 
An object's concept of its internal state?  That thing which if
changed would trigger watcher?

>My 'states', insomuch as I have them, are themselves compound
>objects. The only other approach I am really familiar with is
>*shudder* Merc style "long state_holder" with the "#define A 1;
>#define B 2; #define C 4;" bit container method... and I'm sure you
>use nothing like that.

Ahh, I think I get what you mean.  You mean some sort of enumerated or
flagged "THIS IS A XXX" or "THIS HAS A XXX QUALITY" type indicator.  I
don't have any of that at a server level.  I have objects.  Those
objects have methods and attribues.  Methods are code written in the
internal language.  Attributes are type-less values stored
persistantly in the objects (ie written out to the DB).  If the object
allows (public/private/accessor/etc), attributes can be queried or set
externally, giving an impression of a "state" which can be reacted to
by a watcher.

>:Essentially what happens from there is that the server determines that
>:there is an event to be executed, and calls a specified method on a
>:specified object with particular arguments.  That method then executes
>:from there, calling other methods on other objects etc as needed.  At some
>:point the event terminates, all the changes to the DB are commited
>:atomically, and the server goes back to doing nothing.  

>Can you kill an event if it is invalidated prior to ripening?

No.  I have not been able to think of a good rule for such
invalidations other than the fact that the object that the method is
to be called on doesn't exist any more.  I don't even check for that
-- I just let the event finally ripen, attempt execution, and throw
the exception.

Note: The fact that the original caller does not exist any more is not
necessarily a reason to cancelt the event.

>:Internally the DB, pr at least object ineractions, may be viewed as a
>:message passing system.  Methods send messages to other methods, which in
>:turn acknowledge/respond with messages (possibly after calling other
>:methods).

>Hmmm. I wonder... this sounds an awful lot like my impulse system,
>except that impulses have to travel through existing channels in the
>target object, or they bounce.

I don't have a channel concept like that per se.  The messages are
loosely of the form:

  AuthorityID, CallerID, ObjectID, MethodName, Arguments...

And its just up the the recipient object to do with it or not as it
wishes.

>Now, to the crystal tree...

>There is a bucket with a sympathetic spell to something atop the
>tree, correct? And the tree can only support so much weight, so
>adding water to the bucket eventually overloads the tree and the tree
>crashes down. (nice liquid problem, that... or fluid, at least...
>crystal units begin to approximate sand) Bubba is a physical object,
>that exerts mass reaction to gravity... in other words, he keeps
>track of the theoretically static value of his mass. He has in his
>possesion an object that will be asked to increase mass by the
>bucket, thanks to the spell on the bucket. When the object agrees to
>increase mass, this is passed as a dynamic impulse to bubba, who
>passes it in turn to his location... a tree that cares about such
>state changes, and doesn't like them one bit. It collapses. Unless I
>missed something here, this was never a problem with my impulse
>passing method, as the only way for the bucket to increase the
>sympathetic objects mass was by transmitting an impulse to it, and
>impulses always go merrily down the line.

The CT is not a problem for me either if I code it as above (which is
BTW the "natural way to do it under my system).  The problem enters in
with free user programming.  The problem is that the programmer of the
spell on the bucket DOES NOT have to code it so that the balloon is
informed everytime the weight of the bucket changes.  He could every
easily (and it is almost easier to do it this way, especially for a
newbie programmer), insead program it so that the bucket never
messages the balloon unprompted, and instead the balloon only updates
it weight concept when it is queried externally.

As such, Bubba with the balloon weighs X units.  Bubba stands on the
CT.  60 tonnes of neutronium are added to the (remarkably tough)
bucket, and Lo! unless something causes Bubba's (and thus the
balloon's) weight to be queried,  Bubba continues to stand on the CT
undisturbed.  Now Bubba drops a very heavy anvil, thinking that this
will reduce his weight and allow him to climb onto a thin branch. 
Instead, the CT reacts to the state change by querying Bubba's weight,
which causes Bubba to query the balloon for its weight, and suddenly
discover that he should be a red smear on the forest floor below.

My problem is that I can't prevent twit programmers from coding this
sort of junk, I can't think of a decent reason to allow them to, and I
do want a server that as much as possible enforces building an
internally logically consistant world.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...