discussion:Goals Round III
Sat, 19 Nov 1994 14:37:23 -0800 (PST)
And talking to myself again...
> > - use all the available resources (over net too)
encaspulate resources into named objects which can be referenced
irregardless of location. NOTE: We would take into account the overhead
of using distant resources.
> > - all the above must remain constant over all platforms (who cares what
> > hardware they are using). My app here runs on all my platforms. No
> > multiple shrinkwrap copies.
Same "binary" software runs on all machines.
> > - persistency: This is not really addressed by the above, it could be
> > considered to be part of the user friendliness thing.not only is the ui
> > the same, but the apps and all objects in the system are exactly the way
> > you left them.
When you "shut down" your system, there is the reasonable expectation it
will come back up where you left off. There are two ways of viewing
persistency; idealic, and realistic.
Idealic: Your objects are spread over a number of machines which will
never crash nor corrupt data, or your "top" machine backs up everything
in enough places that all of them will never fail at the same time. Your
system will always work.
Realistic: This touches on "organic" persistency. Instead of fighting
to create the idealic world, we accept that parts will break and focus on
recognizing these failures and allowing the software to "heal" itself.
The healing can take place above the core OS primitives, but below the
HLL. Computers will fail, but where do we allocate the resources to deal
with this and who decides which action to take during a failure? Some
things, such as an IRC session that fails, might be better off being
written off instead of trying to resurrect it later. Based on this it
would be better to let the application choose which OS primitives to
invoke instead of hardwiring it into every object interaction.
Idealic or Organic, which is it to be...