storing Activity parameters

[Gary C Martin]

I'm having some indecision about my own (very simple) activity state  
saving. Just had a though that may add another possibility to this  
thread. What if both journal and file-system were used to store the  
activity state, with the journal settings overriding the file-system  
settings. This way a new activity start-up could inherit the last used  
activity settings, and a specific journal start-up would inherit the  
settings used for that specific entry. So in the case of Speak I could  
have separate favourite journal entries for '3 eyed alien' and another  
for 'Mr square eyes', then if I also just started the activity from  
fresh I'd pick-up whatever the last used setting were (picked up from  
the FS).

My Moon activity isn't complicated enough (just 2 key/value pairs so  
far) to make this much of a time saver, but for my planned Earth  
activity (a port of EarthGlobe, a Mac desktop app I wrote a few years  
back), I'd want to make use of shared location tagging (basically lon/ 
lat markers attached to some metadata) and some more detailed custom  
user settings that a user would not want to make each time. So the  
more detailed user settings (default location, some basic info/notes,  
viewing preferences) would be best going to the FS, and any tagged  
locations would go to the journal (so you could have different  
sessions for making different sets of geotags). I guess in this Earth  
case though there is a more clear separation between settings, and  
activity data. You'd (likely) want just one set of global settings for  
your details, while using the journal to store separate sets of tags -  
though I guess if you change location frequently you might want a  
journal entry for each location* Hmmmmm....

*probably a low usage case for our target audience.

On 2 Mar 2008, at 01:29, Joshua Minor wrote:

> I implemented the save/load feature of Speak without fully
> understanding the other options.  Now that I've seen the recent
> discussion about data vs instance vs the journal I think it would make
> more sense to have Speak save its state in a different way.
>
> On the other hand, the new frame redesign makes it much easier to
> resume an Activity, which would mean that parameters saved to the
> Journal, like Speak does now, would naturally be restored when you
> resume the Activity.
>
> A nice "best practices" document would be very handy.
>
> -josh