Oh, come on. There are RTF viewers and editors for every platform I know
about. And again, the conversion to HTML is straightforward (although
lossy).
> You've suddenly realized that objects are here, and real! Well, good
> morning and smell the coffee Joe! Where have you been? Tsk tsk.
Perhaps you don't understand what I mean by real. I mean real as in on every
PC on every desktop in every home and in every office. (Or however that
goes). I mean like we don't have to wait for apps to be rewritten in object
form -- it's been done already.
> That's why I keep
> yelling at everyone that salvation lies in Virtual Synchrony
> and Ken Birman, ultimately :-).
You know, I think one of the things I'm going to end up trying to do in my
career is reconciling the Ken Birman virtual synchrony view of the world
with the Jim Gray transactional view of the world. (Why me? just because I
work for Jim in a small lab, and Jim's interested in the question, and Jim
and Ken are friends, and because the question interests me. On the other
hand, Werner probably has it all figured out already -- I'm just constantly
amazed how sharp he is.)
Where was I. Oh yes. I compare virtual synchrony and
transactions/checkpointing/logging/recovery for fault tolerance in the
following way. Virtual synchrony works on the "front end" of a
server/process/object, replicating input to keep several objects in an
identical state. The problem of course is that you have to handle ALL inputs
to keep objects in sync, including sources of nondeterminism such as thread
scheduling. This can be hard. Transactional/logging works on the "back end",
after an object has processed its inputs, logging state for recovery as
necessary. The nice thing about logging is that the needs to eliminate
nondeterminism (such as thread scheduling and lock acquisition) and to
synchronize of input (even just virtually), go away. Which I believe in
general leads to easier implementation and better performance, because
there's less work to do. The problem with virtual synchrony and eliminating
nondeterminism is that you end up doing more work more than you have to.
To put this in more concrete terms: you can make a fault-tolerant database
server either by replicating and using virtual synchrony and eliminating
non-determinism in the servers, or by shipping log to another database
server that runs in continuous recovery mode. My intuition is that the later
allows the primary server to run faster (since its input is not artificially
synchronized, nor is its thread scheduling or lock acquisition).
Now of course, the natural way of implementing stable store that can
accessed after node failure is as replicated storage servers. So replication
is still there, it just gets pushed down much lower.
> Generally, I've given up having technical discussions on FoRK.
> I've really come to see things Tim's way. I hang around for the gossip
> and the occassional bits, but I think Tim is right to complain about
> too much techie stuff about XML and objects and stuff like that here.
> It spoils the party. [...]
Hey, wait a moment. We're geeks (yes, I'm speaking for y'all), and we can
geek out at our party as much as we want without spoiling it.
- Joe
(now VERY tired and heading for bed.)
(BTW, tonight's South Park was great.)