From: Josh Sled <jsled@skipjack.CS.Berkeley.EDU>
Date: Sun, 23 Jun 1996 16:35:20 +0800
To: "Vladimir Z. Nuri" <vznuri@netcom.com>
Subject: Re: info assembly line, "flits" (long)
In-Reply-To: <199606222047.NAA26324@netcom14.netcom.com>
Message-ID: <Pine.HPP.3.91.960622202438.18527B-100000@skipjack.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: text/plain


On Sat, 22 Jun 1996, Vladimir Z. Nuri wrote:

> what does today's cyberspace lack to pull off this vision? after
> a bit of thought I think one word to describe it might be
> "continuity" or "persistence". there are so many obstacles in cyberspace to
> transporting documents. it requires too much manual effort
> on the part of each person to translate documents into particular
> formats, send them via email, etc.  what we need is the cyberspatial
> equivalent of continuity: people anywhere can look at the same
> object and see the same thing, and that thing can be moved around
> in cyberspace without ever losing its identity.

The problem is that all that today is handled through the very complex 
laws of physics... think about the the number of atoms that are necessary 
to hold the information for a single page, let alone an entire book...  
in a virtual reality "cyberspace", this would be an insurmountable data 
storage... on the small-scale.

> the problem is that today the concept of a "document" in "cyberspace"
> is merely a concept. I can't point to some "place" in cyberspace
> when I want someone to grab a document from me. I can't say, "here
> it is". I have to go through an artificial series of steps to
> encode the document, such as emailing it, ftping it, 
> uuencoding it, or whatever.

Yes, but you have to go through the same steps in the real world... you 
just don't see it... it's all handled through physics and the properties 
of electron repulsion between an object and your fingers (holding 
something) and light coming from a light-emiting source, being 
absorbed (in part) by an object and reflected toward your eye, 
which interpretes it (seeing something).  These are enormously complex 
tasks, far more so than uuencoding and e-mailing... but we don't 
recognize it because it's handled for us automagically.

> what I am getting at is that we need a kind of virtual reality to
> pull off the information assembly line to its utmost potential. I
> believe we literally need to create a visual metaphor for the 
> information assembly line that transcends the concepts of email,
> different computers, etc.  I should be able to "pick up" and "move"
> a document in cyberspace as easily as I move a piece of paper in
> the real world. the whole system of different servers, different
> software packages, different protocols, all this should 
> be *invisible*  to me in the same way it is invisible on the current
> WWW.

I think the thing that's most important in this sentence is _"move"_ ... 
this is the main problem for computers... it's SO easy to DUPLICATE 
information... but near impossible to make sure that you've MOVED it... 
if it was easy or even possible to MOVE something on a computer, 
the whole double-spending ecash argument would be kaput, as would the 
"wiping" a file vs. deleting it... I think that's what you're getting at, 
rather than the visual metaphor... which could be EASILY created.

> imagine that one actually created a total virtual reality 
> information assembly line. what kind of form would it take? you
> would see different things that can be done to documents
> as "tools" that can be applied to them. you would see their
> locations as simple visual metaphors that ignore the concepts
> that segregate information. for example, you might see a single
> file cabinet that represents every record in an entire company,
> regardless of its location anywhere in that company. tough to
> pull off? of course, but this is what we are headed towards, in
> my opinion.

Who says that this doesn't exist today?  The file server which I'm on 
says that there's a file in my "home directory" on "this" machine 
(skipjack.cs.berkeley.edu) called index.html... and if I went to the 
computer next to me, it would say that there's a file on the machine 
hornet.cs.berkeley.edu of the same name... but in reality the file is 
somewhere within a block of me on the machine cory.eecs.berkeley.edu... 
it's the same thing, just with a nice visual metaphor slapped on front.

> the concept of a bit is too abstract for me. for a virtual reality
> and an assembly line, I would prefer to say that information has
> two additional components other than a binary true/false value:
> a *location*, and a *time* that it is at a location. in this way
> information better matches our reality that we deal with every
> day. I would say the "flit" concept is a pivotal missing link
> in creating an information assembly line.

And key to the flit concept is the moving concept that I alluded to 
earlier... these flits could only exist if A) you had trusted|responsible 
software that moved them or B) they could ONLY move... like an atom... 
you cannot copy and atom... and to pull off what you're talking about... 
you wouldn't be able to copy a flit.

> this requires a somewhat radical shift in current technological
> thinking. currently we see data as stationary stuff that sits
> in some place, and people come along and run programs that
> churn up the bits and spit out new bits. but the new bits are
> not nicely tied to the old bits except through our own memories.
[snip]
> instead I would say that the key concept of information is to
> say that it has a content and a state at some time. a document
> composed of a bunch of "flits" can be broken up into its 
> component "flits", and the "flits" can be sent in different
> directions and recombined into different documents. but because
> they are "flits", I can *trace* their destinations over time.
> 
> what does this mean? it is the concept of debugging applied to

It means that you'd have an INSANELY large ammount of storage for a 
single small document.

If each flit was, say, a single bit in the document... you'd have almost 
atomic-like storage for a file... each part of each character would have 
a revision/tracking history...

But, if you're thinking on the document level... all you'd really need is 
a good compound-document technology (similar to OpenDoc) with a great 
revision history (similar to OpenDoc) that not only tracked revisions 
done by humans... but also revisions and handling done by programs.

> information technology. imagine that I once had a document, and
> I want to know what happened to it. because it is made of 
> "flits", I could say, "where did the flits that comprise this
> document go?" I would get an answer about their entire history--
> what programs the moved through, how they were recombined, 
> where they now reside. I could trace backwards too. "where did
> this flit come from?" -- the system would trace the origination
> of the flits.

Where would all this imformation be stored?  It's far too much for any 
filesystem or computer or harddrive in existance...

> what the flit concept does is introduce a *context* to a bit.
> a bit has no "context".  where did a bit come from? the situation
> with information is that it always has a *context* and is tied
> with other information. (so in addition, I might like to suggest
> that "flits" can be "tied together" with each other).

But bits aren't supposed to have context... they're just a state of 
being... on or off...

> when today's software spits out some document, there is nothing
> necessarily tying that document with the original input except
> the memory of the humans. I would suggest that the information
> assembly lines of the future will replace this concept. nothing
> will be left to the imagination. things that are part of people's
> memory today will be made explicit in the systems of tomorrow.
> the abstract concepts we have of systems being "tied" together
> will look very embryonic and impoverished compared to these
> new techniques.

But how about another approach... instead of the software spitting out 
a document... it gives back a combination of a document and the spit-out 
document... listing what's changed: revision control.

> "flits" would have an identity irrespective of companies. one
> could track them moving through different companies if necessary.
> (the "flits" might therefore also have security aspects associated with
> them.)  the point is that the data must not be disconnected, it
> must be seen as continuous, and I think a flit-like concept is key
> to accomplishing this.

Unfortunately, data IS disconnected... the only thing that makes it 
connected is what we impose on it by saying that a file stops when the 
EOF is reached, and in a particular file format, this character means "foo" 
and that character means "bar", etc... this is what makes data continuous.

> notice today how much our systems diverge from the flit concept.
> we are always losing bits, and not tying them together. whenever
> a system goes down, all those bits evaporate. this would not
> be acceptable in a flit universe-- it would be like an object
> suddenly blinking out of existence. obviously we don't consider that
> an acceptable behavior of objects in our current reality, why
> should we allow it in cyberspace? cyberspace has a long ways to
> go. today's cyberspace is barely sufficient for what is required.

But cyberspace is NOT real space... if it was, we'd require computers the 
size of this planet to store and process eveything.  Cyberspace is a 
computer-generated space... and computers are far from powerful enough to 
keep up with what you propose... and I suspect that they will be for a 
LONG time to come.  I think a computer-generated approach is a lot better.

> in a flit universe, I would like to see flits "pile up" in a
> queue when a machine breaks, like what happens in a real 
> assembly line. the assembly line metaphor is really crucial
> here. imagine that on some assembly line, all your objects
> suddenly disappear when a machine anywhere on the assembly
> line breaks. you have to then run other machines to "bring
> back" the flits. a ridiculous concept. instead, I'd like to
> see flits pile up when some machine goes down on the assembly
> line. once you get the machine running, it automatically starts
> back going through the flits.

assembly-line = server program
assembly track = queue based in permenant storage (hard drive, static 
	ememory, etc)
machine breaks, assembly-line program dies... machine comes back up... 
assembly-line program starts... continues to process queue on permemant 
storage... difference?

> a lot of this implies "transaction tracking" by conventional
> standards. I would suggest that "transaction tracking" and
> integrity assurance are only the barest rudiments of what is
> required to pull off an information assembly line. the 
> belief that these are now considered incredibly cutting-edge
> and state-of-the-art technologies
> is a good indication of how far we have to go.

VERY VERY VERY far...

> I mentioned Moore's law above because I think it takes care of
> all objections that "so and so that you are proposing would take
> too much time". imagine that we have virtually unlimited 
> computational capabilities-- what could we then do with this
> kind of power? tracking "flits" would be an excellent use
> for all this power, imho.

Well.. that's what i'm saying : "It'll take too much time".  But, 
considering Moore's law... you may be right... in a universe with 
"virtually unlimited" computing power, this, and a lot more, would be 
possible...

Josh