Journal Suggestion

[Eben Eliason]

On Tue, Apr 29, 2008 at 7:42 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> Hi,
>
>
>  On Mon, Apr 28, 2008 at 9:26 PM, James Simmons
>  <jim.simmons at walgreens.com> wrote:
>  > I, too have suggestions for the Journal:
>  >
>  >  1).  The Journal should show, as a percentage perhaps, how much disk
>  >  space is free in the Journal, or in whatever removeable media (SD card,
>  >  Thumb drive) the user is currently looking at.  It should give some kind
>  >  of warning cue when the disk space is dangerously low.  The Freevo PVR
>  >  project does something like this.  A full Journal drive can make the XO
>  >  unbootable.
>
>  Showing the amount of free NAND space is already implemented in latest
>  joyride images.
>
>  http://wiki.laptop.org/go/Designs/Frame#11 shows how this would work
>  for removable devices, but it hasn't been implemented yet.
>
>  I think that Eben wants a notification when the journal is getting
>  filled, but the XO shouldn't be rendered unbootable anyway if the NAND
>  fills up.

Yup.  The design for "space used" is much needed.  The mockups Tomeu
points to illustrate how that will look.  We also need to do a much
better job of feedback about various pieces of information, including
low battery, low NAND space, etc.  I hope to launch an assault on this
kind of feedback for the upcoming release.  In the future, of course,
we hope to go even further with the Journal problem by introducing a
"falloff" mechanism by which old, unused, and "unwanted" entries can
be deleted automatically (assuming they have already been backed up to
the school server and are thus recoverable).  We need to put a lot of
time into getting this right, though, so in the short to medium term,
we'll probably just ask the kids to manage this.

>
>  >  2).  The problem with custom metadata like page numbers not being saved
>  >  across a reboot should be fixed.
>
>  Yup.

Yes!  This is a huge bug!

>  >  3).  Metadata should be saved when the user is loading data from
>  >  removeable media.  For instance, if I keep books on my SD card or thumb
>  >  drive, I should be able to return to the saved page number, and also see
>  >  a screenshot of the page I left off on.
>
>  Yes, I'm not sure if we have agreed in a way for storing metadata in
>  removable devices.

Well, this has been a point of debate. Some feel that absolutely
nothing should change on removable media unless the user specifically
copies to it or modifies files on it.  It's very questionable if
"reading a pdf on my USB drive" should amount to "modifying the pdf on
my USB drive".  I'm actually leaning towards no on this point, to
retain the idea that the Journal itself is the thing which retains
history.  Files which aren't in it are thus not versioned.  That seems
like a clear distinction to me, and one that can be learned.

The addendum to this idea, which stems from the new Journal designs,
is that the Journal can record actions on objects that don't actually
reside in the Journal, which in some sense gets around the issue.  For
instance, it could say "You read all_about_sharks.pdf on
your_USB_drive today".  The Journal entry records the action, and the
metadata (such as the page you stoppped on), but keeps only a
reference to the file on the USB drive, instead of manually copying
it.  You could resume this entry only when the USB drive was present,
of course.  This opens the dangerous door of aliases, which is why
we've been operating under a copy-almost-everything model, so that
it's always possible to resume old entries.

We'll have to see how this plays out, and to what extent it's needed
to use the USB drive as a working directory of sorts.

>  One option is to store "actions" as a zip file that includes all the
>  "objects" and metadata for them. This has the inconvenient of having
>  to unpack the zip if you insert it in any other desktop system.
>
>  Another option is to have a hidden directory in the device with a text
>  file for every action that contains its metadata.
>
>  The current approach of storing the metadata inside a Xapian index in
>  every removable device hasn't worked very well.
>
>
>  >  4).  It should be possible to specify for certain Activities that they
>  >  should *not* create Journal entries, ever.  I'm thinking of the Terminal
>  >  activity and the Log Viewer activity specifically.  The entries for
>  >  these activities don't preserve the state of when they were last used
>  >  (and probably should not do so) so there isn't much point in making
>  >  Journal entries for them.  Resuming them is no different that launching
>  >  them anew from the menu.  We already have a way of specifying that an
>  >  Activity not appear in the menu.  This would be an extension of that idea.
>
>  Yes, there may be some cases when a journal entry won't give any value
>  to the user, so it makes no sense to write an entry.

Actually, I can still see arguments for wanting both of these types of
things around.  For instance, the Terminaly absolutely *should* be
storing it's state.  It should retain the environment variables that
have been set; it should retain any aliases that have been defined; it
should retain the command history for recall later; and it should even
retain the scrollback buffer so that I can review what I worked on
before the next time I resume.  I think this would actually be a great
thing to have!

Of course, this argument goes hand in hand with the desire for a
future "smart Journal" which can detect stagnant entries which haven't
been touched since creation, and places them high on the list for
removal.

>  >  5).  For extra credit, make the Journal able to do something with
>  >  read-only removeable media like CDs and DVDs.  I'm thinking for instance
>  >  of letting the user copy a file from a CD into a new Journal entry.
>  >  Obviously not needed for the XO, but if Sugar was to become a product
>  >  separate from the XO but aimed at the same audience (poor children
>  >  needing education) this would be a useful feature.
>
>  Definitely.

Yup. I don't see any problems here.

- Eben