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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
