[sugar] Journal integration design for Measure Activity

[Mike C. Fletcher]

Tomeu Vizoso wrote:
> Hi,
>
> follow some comments on the suggested alternatives from Mike:
>
> On Mon, 2007-10-22 at 16:36 -0400, Mike C. Fletcher wrote:
>   
...
>>     * Provide a mechanism in the Journal to flag a given entry/file as
>>       "time-shared" with its future instances
>>           o Activities which are "workspace-oriented" in nature (mail
>>             clients, joke-collection managers, photo managers) would
>>             mark their stored "workspace" items as time-shared, and
>>             would automatically attempt to load the last record in the
>>             Journal.  That would require an extra API in the Journal to
>>             allow safe (non-metadata-leaking) requests to retrieve lists
>>             of the time-shared values.
>>           o Activities which are "document-oriented" in nature (word
>>             processors, audio-file editors, video editors, etc) would
>>             only mark their "settings" (or a subset of them) as
>>             time-shared, and would attempt to load them automatically,
>>             while not restoring the last-run-file(s).
>>     
>
> I think (Eben should confirm), that "workspace-oriented activities"
> doesn't match quite well with our current concept of Activity. The
> journal is intended (not there yet, lots of work left to do) to give a
> good browsing experience for all the content that is kept inside the
> laptop. So that if the user wanted to find a jokes collection, he would
> go first to the journal and find it either by filtering, searching or a
> combination of those.
>   
Straightforward examples of activities requiring state restoration for 
most natural use cases:

    * Email clients (collection of all email so-far received)
    * Telephones (connection/setting information)
    * I.M. Clients (connection/setting information)

Less straightforward:

    * Jukeboxes (arguably, though some people use them in a
      playlist-document-centric mode)
    * Budget/finance activities (again, arguably, most people just have
      one set of books, others handle many sets)
    * IDEs (again, preference of the user, my own is not, but lots of
      people auto-restore when they only work on one or two projects)

in each case you *could* have the user load up a stored state manually 
each time.  In some of the cases it's really just user/developer 
preference, but we as a platform should *not* be dictating user 
preference AFAICS.  The second set would all work fine with the "choose 
the last entry from a pop-up of last entries" approach.  The first set 
really doesn't make sense without the settings and/or past-content 
available.

As mentioned in the other thread, almost all activities need 
settings-storage functionality (once they grow past a certain point) so 
that they can be customised by the user to work as they wish, regardless 
of whether their "content" is time-shared or not.  You could argue that 
you should have a different activity for each type of preference, but 
that seems likely to produce a nightmare wrt release management and 
project proliferation.
> If any activity author thinks that his activity could give a better
> experience in browsing all the content created within it, please pass to
> us your requests for improving the journal. Preferably as trac tickets.
>   
That's actually a step farther than we need, I think.  We're talking 
here about the ability to request from the Journal a set of elements (or 
potentially just one) that has been explicitly marked by the creating 
instance as time-shareable.  That is, restore-last-state is the base 
requirement.  Bitfrost has a protection bit for the "see everything of a 
type" case, incidentally, so a photo-browser could be granted access to 
the set of all photos on the machine already (at least, in theory).
> We also think that a good way to improve this situation is to make it
> easier to resume existing entries in the Journal. Mike's ideas below are
> good, any other in this direction would be greatly appreciated. But
> remember that the user needs to know at every point to which data an
> activity is being granted permission.
>   
Yes, we do need to be sure that the user is aware, or that the 
application has been explicitly granted a privilege for this type of access.
>>     * Provide a shell-level UI control on each frame activity icon.
>>           o On clicking (or hovering) it brings up the Journal set
>>             produced by that activity (say the last 15 entries from the
>>             activity) to be directly launched.  That is, a recently-used
>>             Journal-list for each icon, but the default would still be
>>             to create a new instance without access to your previously
>>             created files.
>>     
>
> This has been discussed, could be implemented for 1.1.
>   
Alright.  As Bert noted, this doesn't really address his concern (he 
wants natural-one-click-default action to be restore), but I would think 
it would help with many activities.  If we were to combine it with the 
ability to mark a given activity as P_LAST_USED, it might suffice for 
him (if I understand correctly).
>>           o Alternately, launch the Journal with a pre-selection query
>>             from the control.
>>     
>
> This is scheduled for 1.0. Activity icons in the frame will have an
> option in the palette that will show the journal filtered by that
> Activity. See #4275.
>   
Fair enough.  This is fairly intrusive as a launch operation (probably 
why Bert isn't seeing it used with his test "group"), but it is 
functional and likely all that can be done today.
>>     * Provide just a BitFrost protection "P_LAST_USED" that signals that
>>       the application should always be given access to the latest
>>       Journal entry from that activity (all other access (i.e. switching
>>       workspaces) would require explicit authorisation)).  This
>>       effectively just prevents "random" choice of Journal records, and
>>       reduces the attack surface to just the last items stored.  Of
>>       course, information-leakage attacks are generally the most
>>       valuable with recent data, so it's not a perfect solution.
>>     
>
> If the user wants to start an activity, has he given it the permission
> to access the last activity instance data? The user should remember
> which was the last thing he did in that activity before using that
> option?
>   
Yes, they would be granted access, hence the application of a Bitfrost 
protection bit.  That is, this is a potentially dangerous action.  
Activities can be granted the permission by the user, or by their 
installation bits (with all the implications on signing, 
mutually-exclusive bits and the like), but they do not by default have 
the ability to access the last item.  Only when granted the permission 
bit are they able to employ this functionality.

The catch here (with a "last entry" approach) is that large activities 
may well have two (or more) separate pieces of "last" content, i.e. 
their settings and their workspace.  The idea of marking pieces of 
content time-shared was to allow for such multiple-element access, 
though it wasn't particularly well spelled out.  We might take the 
approach of allowing an activity access to each last-entry for each 
content-type saved (i.e. you would have access to both the last 
x-settings/my-act and x-content/my-act entries).

We have a commonly desired operation (state storage and retrieval) that 
is required by whole classes of activities, and useful for almost all 
activities.  While I want to make sure we address the security issues in 
a consistent way, I think we really do need to provide support for 
alternative design choices for activity developers.

With thanks,
Mike

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