discussion:Goals Round III

[Mike Prince]

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...

Mike