[sugar] Resuming by default

[Mike C. Fletcher]

Bert Freudenberg wrote:
> You guys are caught up way to deep in technical detail already. I'd  
> place the desired user experience first, then see if this has  
> security implications, and then worry about implementation.
>   
Bert, I realize that you've been doing a lot of the heavy lifting in 
trying to get us to open the platform, so obviously we need to listen 
closely when you raise a point like this.  I really do appreciate your 
efforts here, and I'm sorry if I've missed something.

My comments were of the nature of "Yes, that is an important, useful and 
widely required functionality, please consider the security implications 
in your design of it so that we can get it done ASAP".  The suggestions 
I was trying to put forward were intended to allow for both "clean 
slate" and "resume-by-default" activities.  I would *strongly* agree 
that we need the *ability* to support "resume-by-default" when that is 
the natural format for an activity.

As an aside: almost *every* application has time-shared information, 
namely user settings that are desirably shared automatically without 
effort by the user.  Having a way to mark particular elements in the 
Journal as time-shared and allowing the new instances access to that 
information is very desirable.  I just want to make sure that in 
providing that functionality we do not subvert the protections of the 
security system.  Questions such as whether you see "settings" data in 
the default Journal view will need to be addressed as well.
> So I think not resuming by default is a real obstacle to making good  
> use of the Journal idea.
>   
Resuming by default is a particular application design.  Starting fresh 
each time is another design.  Neither is necessarily correct or proper, 
they are design-time (or even run-time[1]) decisions that should both be 
supported.  Your own experience with porting eToys to the platform has 
shown that making such application-level design decisions at the OS 
level causes all sorts of problems, particularly when porting 
already-extant code-bases.  The OS should support *either* approach.

With respect,
Mike

[1] And really, I would consider whole-state restoration more of a user 
preference for *most* activities, though obviously a Squeak/Smalltalk 
system has a natural tendency toward state-restoration as the preferred 
approach.

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com