Archives and Backfollows

[Eric Dean Tribble <tribble>]

Marcs asked:

   While hugh and I were discussing links as first class entities versus
   links as components of documents, an interesting question came up:
   when you do a backfollow on a document, will the system want to look
   through the archives to find links, or will there be enough info 
   on the disks so that xanadu can tell whether or not there are links
   sitting out there? Can you tell what my question means?

I see pieces of two questions:  will the backfollow operation want to
look through the archives for links, and how will it be able to
backfollow things that actually are in the archives?

1) The backfollow operation is weak in the sense that if something isn't
avaiable, backfollow does not report it.  Berts in the archive are
implicitly in the partial part of the orgl created by a backfollow
operation.  That means that they will appear in the partial orgl
as soon as the system notices that they are there.  The net answer is
that the backfollow request won't make recover requests to the archiver.

2) Answer (1) implies that the backfollow never returns Berts in the
archive.  This is only true if an entire Bert is purged.  Notice that
most of the storage in the system will be at the data-end (south) of
the ent.  The upper indexing structure isn't particularly significant,
so if you can manipulate the data (i.e. it's on disk), then the
indexing structure back to all the stamps that contain it (and the
Berts on them) are probably also on disk.  Given the properties of
EAddresses, we can keep parts of works on disk while keeping the rest
on archive.  I expect lots of link spaces to remain on disk while the
rest of the work containing them gets flushed.

A couple ideas are bouncing around in my head for just keeping the
filtering information for archived Berts, but they all feel bogus.
I'll worry about it if it actually becomes an issue.

dean