[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
version compare and partial orgls
- To: <michael>
- Subject: version compare and partial orgls
- From: Eric Dean Tribble <tribble>
- Date: Sun, 3 Sep 89 16:34:40 PDT
- Cc: <mark>, <us>
- In-reply-to: <Michael>,25 PDT <8909032210.AA08050@xxxxxxxxxx>
Date: Sun, 3 Sep 89 15:10:25 PDT
From: michael (Michael McClary)
I think the correct analogy isn't equilibrium in economics, but
simultaneity in cosmology. Another non-existent phenomenon, which
biases your thinking away from relativity toward newtonian mechanics.
The communication delays/omissions between backends make it a nearly
isomorphic problem.
Interesting. I think I agree. (I think we all agree...).
What happens when the bert has moved around to several machines, without
taking the data with it, and the document is edited on all those machines?
Can an orgl ever know it's been completely informed? (This may seem silly
for text documents, but for documents with sparse coordinate spaces it
may be the natural thing to do.)
Yes. Being data-complete makes sense, even for sparse documents.
Imagine an acad drawing. The drawing doesn't entirely fill its
bounding volume, but could still be complete. There can certainly be
Stamps that are never complete: the orgls generated as the results of
backfollows, for example.
I don't want to discuss bert migration right now....
When you delete-to-archive, don't you need to "uninform" the orgl?
Yes. The last line in the semantics document addresses this issue.
uninform is required for archiving, but we not for general users, so
it is not defined in the 'user' semantics. I admit this was a bit of
cop-out to postpone disinform issues till I need to finish the
archiving design (an admirable cop-out, though).
dean