From: "Vladimir Z. Nuri" <vznuri@netcom.com>
Date: Mon, 24 Jun 1996 13:18:46 +0800
To: blanc <blancw@accessone.com>
Subject: Re: info assembly line, "flits" (long)
In-Reply-To: <01BB6068.3EA6BA80@blancw.accessone.com>
Message-ID: <199606240013.RAA25268@netcom10.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


well, already I'm forced to elaborate on flits when I was
going to do that in another essay. oh well.

>
>
>Wouldn't this accounting of "flits" require that each of them be =
>assigned a tag?  =20

after more thought, I don't think a flit would only be 0 or 1. 
the flit would have different granularity based on what the system
can afford. we might start out by saying that every document
is one "flit", i.e. that is the basic unit. then when we get
a more powerful computer, the form is broken up into multiple
"flits". finally, when God finally designs the ultimate computer
<g>, we would then let every bit in the universe be considered
a flit that has a location in cyberspace at some time.

>Since this would encompass all the "flits" in cyberspace irrespective of =
>who/where used them, whose "flits" would be counted first, beginning =
>where?  =20

not sure about what you mean by "counting" flits.  the concept
of a flit would be very roughly analogous to something like
what email is today, except that the email would never be 
considered to have a permanent destination. every time you
move the flit, new header lines would be added to the 
history tracking of it. what is remarkable is that this 
paradigm gives you incredible tracking control over information
that is going to be necessary in the future, imho.

>And once one "flit" was attached to a document which was maintained as a =
>permanent structure somewhere in someone's database, that means it could =
>not be used anywhere else, and how would this work for copies made of =
>that original document? =20

the documents and flits are interchangeable. the document does not
have flits "attached", the document *is* a flit, or comprised of flits.

some of the properties of flits: they can be copied, but the 
child flits might "know" who their parents are, and can always
find their parent.  notice how radically different this is from
the modern view of information as lumps that sit in disconnected
piles. when I use a "cp" command, I do indeed get a copy, but I
have no idea about the origination of that copy. the flit concept
establishes *context* to information, and makes the context 
intrinsically part of the information. the information cannot
exist independent of context. today, our computers give us
contextless information, and all the structures we have built
are designed to attach context when it should be attached at
a much lower level, imho.

>Once a "flit" was used as a copy and then detached and re-associated =
>with some other document several times, would each new copy carry a =
>record of where it had been previously, so that half of the amount of =
>space of a document would be comprised of the historical record of where =
>that "flit" had been?

again, it can be implemented at different levels. many companies
already have "revision control systems" that are flit-like mechanisms
working at a document level.

>Sounds very costly.

ah yes. indeed. not saying it can be pulled off this moment.
two words: Moore's Law.