[sugar] Resuming by default
Mike C. Fletcher
Tue Oct 23 09:27:51 EDT 2007
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) 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.
 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
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Sugar-devel