[sugar] Resuming by default

[Tomeu Vizoso]

On Tue, 2007-10-23 at 09:27 -0400, Mike C. Fletcher wrote:
> 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.

Agreed with that, but who has been talking about concrete implementation
details?

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

Activities can already store configuration data that is not tied to an
activity session in their own profile dir (env var SUGAR_ACTIVITY_ROOT,
something like ~/.sugar/default/<activity bundle id>).

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

I certainly see it not only activity dependent, but also dependent on
how a particular user uses a particular activity.

And having some activities resuming by default and some others showing a
blank sheet, looks like confusing to me... How can we explain that
distinction?

About making easier to resume existing entries, well... I have already
said that we aim to improve this situation. Any other ideas in this
direction are welcome.

Tomeu