[sugar] Journal integration design for Measure Activity
Mike C. Fletcher
Tue Oct 23 10:03:22 EDT 2007
Tomeu Vizoso wrote:
> 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)
* Jukeboxes (arguably, though some people use them in a
* 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
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
> 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
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.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Sugar-devel