From: Robin Powell <rpowell@algorithmics.com>
Date: Fri, 28 Jun 1996 07:16:37 +0800
To: "Josh Sled" <jsled@cory.EECS.Berkeley.EDU>
Subject: Re: info assembly line, "flits" (long)
In-Reply-To: <199606241741.KAA10522@cory.EECS.Berkeley.EDU>
Message-ID: <96Jun27.131433edt.20485@janus.algorithmics.com>
MIME-Version: 1.0
Content-Type: text/plain


>>>>> In article <199606241741.KAA10522@cory.EECS.Berkeley.EDU>, "Josh Sled" <jsled@cory.EECS.Berkeley.EDU> writes:

    >> flit. I agree, a flit as a 0 or 1 is very unlikely in the near future.
    >> but at a document level, i.e. a document as a flit, we already have
    >> it in RCS systems that companies are struggling to implement well
    >> as we speak.

    > Again, I think a document system is the best suited for information
    > storage... the flit concept seems to be a great overkill.

Another basic problem that I'm surprised hasn't come up yet:

If I have a 1-bit flit with full revision history, don't I have to
have revision history on each of the bits of the revision history of
the original flit?  We're talking an infinite amount of storage space
here, for one flit that has been moved once!  Also, revisions for the
individual bits in program, including the programs to keep track of
flits, including revision history of programs in main memory, from
what it sounds like.

We will never have this much storage space.  An infinite amount is
required.  What would be the point anyways?  Makes a lot more sense on
a per-file basis.

-Robin