New things in the backend

[Eric Dean Tribble <tribble>]

Sensors are session-level objects that have a single no-argument
   no-wait message ("ring") that gets sent to them when the piece of
   partiality they are attached to gets filled in. There needs to be some
   way of removing them from the ent when they are deleted or when the
   session ends. Right now they live in an ImmuSet inside a PartialLoaf.
   Should they be dependents? 

They don't need to be dependents.  Partial Loaves should just destroy
all sensors when they get destroyed.  Is that the only reason they
might need to be dependents?  I don't consider tracking destruction to
be part of the dependence mechanism (it's at a different semantic
level than stateful operations).

	What happens if the loaf gets sent to disk?
The variable containing pointers to sensors should not be a copy field,
so that it doesn't get carried to disk with the loaf.  I think it
should continue to exist in memory even when the loaf is on disk.  It
might even make sense for it to not be a field of the PartialLoaf but
rather a separate HeaperSpace table that acts as a soft field.

   Should a loaf with sensors be prevented from going to disk?
No.  Otherwise we couldn't write out any changes.

   HopRecorders are attached to a bert and fill in a partial orgl with
   some information each time the bert is hopped. They should persist
   across sessions. I don't know how one would get rid of a HopRecorder
   once it`s created.

The hopRecorder goes away when the PartialOrgl that it informs goes away.

   A HopRecorder is a kind of Waldo, wrapping a Foot,
   which grabs a Stamp on the partial orgl it is filling in. It is in an
   ImmuSet of the Bert that it is watching. What does it take to make it
   persistent?

I suspect this means that Manipulator must be a subclass of Shepherd.
Then all of this should go to disk just fine.  We will need to worry
about the collection getting too big for a Snarf (we may have to use a
Grand-collection of some sort).

dean