[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: <tribble>
- Subject: "Version" Aversion
- From: Mark S. Miller <mark>
- Date: Mon, 11 Dec 89 22:48:54 PST
- Cc: <bobp>, <xanatech>, <bobp>, <joel>
- In-reply-to: <Eric>,01 PST <8912120458.AA08247@xanadu>
Date: Mon, 11 Dec 89 20:58:01 PST
From: tribble (Eric Dean Tribble)
I'm not sure cross-machine hopping of Berts is that far away. We can
get much of the capability by letting Berts get hopped remotely
(without migrating them). The normal double-bert scheme for editing
let's us edit efficiently.
Yes, the double Bert scheme means it's very low overhead in the case
of a local "edit"-Bert and a remote "session"-Bert. After first
product, inter-machine migration of Berts is probably doable, but
still has the problem that at any one time the Bert is on exactly one
machine, and so may get lost.
However, I now realize that multi-machine Bert hop (e.g. via
migration) is still a much simpler problem than general distributed
transactions. To get to the latter, we would have to offer a
multi-Bert grab, such that different parties can request different
(potentially) partially overlapping sets of Berts, and all this gets
resolved without deadlock or starvation. And without trust. That's
the one I'm worried about.
So you're right. Multi-machine/Single-Bert hop may not be that far
off. It'll be interesting.