Re: Random namespace pruning

[AI.LOEFFLER@MCC.COM (David D. Loeffler)]

Thanks for the input.  I have a few other questions and comments.
1.  What happens if you turn off versions when the machine on the net reboot.
    I thought there was a timestamp cached in the world and the lispm checks
    this with a nameserver.  If the number is lower than the lastest one but
    still in the range then the server sends that machine the updated inform-
    ation between the two timestamps.  If the lispm's timestamp is too old and
    not on the server any more then the lispm reloads the namespace.  Is the
    model of operation correct?  If it is then does it mean that turning off
    the changes file will force all machines to reload the namespace at
    boot time? (or validation time - we have ours check once a day).
2.  I have now rebooted my isolated machine about 6 times and reloaded the 
    namespace several times.  I now have what I believe to be a consistent
    set of 5 namespaces that all run on one machine.  There seems to be a
    few things I should say about what I have learned for other people wanting
    to create more than one namespace on a machine.
    a.  After logging in I do a (net:set-site :my-first-namespace) and it
        does the usual prompt for host and location.  The host is "local" for
        me so I just do a <return> but our location is different than the default.
        we keep our namespace files in >sys>site>namespace> instead of >sys>site>.
        Our users edit files in >sys>site> and we found it was easier to care
        for the namespace if we keep the files in a separate directory.  So,
        for the location prompt I just have to type in "namespace>" and it is
        merged correctly into the default pathname.
    b.  The search list is each namespace object so I get prompted for the 
        server and location of the MUMBLE-namespace.text files.  Again, this
        is host local (<return>) and directory "namespace>".  However, this just
        creates an empty shell for each of these namespaces.  The net:set-site
        function continues to load all the files for :my-first-namespace and
        I get warning for objects referenced in it to the other namespaces.
    c.  I then run a form to map over all the namespaces and check their validity.
        (dolist (namespace '(:my-first-namespace :my-second-namespace ...))
          (send (net:find-object-named :namespace namespace) :check-validity nil t))
        This forces each of the namespaces not already loaded to load.
        [it could be that Chris's form would do the same - ie, to map over the 
        namespace objects in neti:*namespace-search-list* and force them to
        unload and then ask for the latest timestamp. - I am not sure if
        this is exactly equivalent but may give the same result in this case]
    d.  On network objects I created a nickname on all but the ones in :my-first-namespace
        where the nickname is MY-FIRST-NAMESPACE|CHAOS for chaos net and likewise
        for INTERNET.
    e.  In all the other MUMBLE-namespace.text files I made sure that the file 
        references where of the form MY-FIRST-NAMESPACE|THE-NAMESPACE-HOST:>mumble.text
        where THE-NAMESPACE-HOST is defined in MY-FIRST-NAMESPACE and not in the 
        other namespaces.  The search list in each namespace will let this host
        be found evenly but I wanted to be sure to enforce that this host is
        in MY-FIRST-NAMESPACE.  Similarly for all host references to the
        primary namespace server.
3.  I would like to know how the pruning operation works when you build a new
    world on the server.  My experience is that the first changes file written
    after boot has all changes before the timestamp as of the save deleted.  
    The timestamps are still there but with empty entries - (it has been a while
    since we did this so my memory may be off).  This cause problems for machines
    that have older worlds.  I would like to have the server not reap the
    changes file or maybe I will take Chris's suggestion and just get rid
    of the changes file - on our machine this takes about 35+ blocks every
    time it is written.  If the changes file is not included in the mumble-namespace.text
    file then is there still an in core image of the changes still kept or
    is it set to nil?  The reason I ask is that I can usually spot a problem
    with the namespace by seeing the changes file's size decrease (usually from
    about 35 blocks to 5 blocks).  I would like to know if there are any utilities 
    I can run on the server machine that would check the health of the namespace.
    When our changes file drops in size I would have to hand edit it and then
    reboot the machine.  The reason for this is that the incore image of the changes
    is corrupted and other lispms get incorrect information when they boot or check
    on some object.  If I did not fix the problem quickly I have users editing 
    namespace objects to "fix" things they though were there but that someone must
    have deleted or changed on them.  What happens when you delete the changes
    file when machines with older worlds boot?
-------