Journal Suggestions

Eben Eliason eben.eliason at gmail.com
Wed Apr 30 10:47:50 EDT 2008


On Wed, Apr 30, 2008 at 10:15 AM, James Simmons
<jim.simmons at walgreens.com> wrote:
> To be truthful I would be perfectly happy if the SD card just had metadata,
> including screenshots, like regular journal entries have.  The other Journal

Quoting Jameson:

"Technically, I think this would mean that the metadata are stored on
the NAND, with some UID of the associated file. The file, if not
present on the NAND, would be looked for on SD, USB, and then server,
in that order."

And quoting myself from the other thread on the Journal designs:

"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 may find a good way to handle this type of approach.  It's still
not inherently correct.  For instance, even if we store the metadata
on NAND and reference another object on an external device, there's a
question of whether or not we redundantly store that metadata on the
device itself.  Without it, we keep the USB drive (for instance)
clean, as many have claimed we must do.  On the other hand, without it
we can't ever truly restore from that device, which is a firm
requirement of the backup server.  So there may still need to be
differences...perhaps instead we always keep the local metadata, but
we have the option to treat external devices of any kind as Normal or
Backup devices.

Assume the above for a moment.  As I mentioned before, saves will
always save into the Journal (by default, at least).  If we open a pdf
from the Backup SD, we'll get an entry in the Journal for that.  Do we
also get an entry on the SD?  Are there mirror entries?  Conversely,
do actions I take on objects in local NAND get mirrored in the Backup
SD?  If we want to treat them as local backup, then yes.  But perhaps
this is again not the use case you had in mind, in which you wanted
metadata actually *on* the device.  For that matter, what reasons
might you have for needing the metadata on the device itself other for
backup, assuming you can actually manage all of the history within the
Journal, and reference the files which live on the external drive?

The other problem is how and when to handle aliases, and how to expose
that to kids.  For instance, we've been operating to the extent
possible under the assumption that we'll copy any files used or viewed
into NAND so we can retain the history locally, and so kids don't have
to always think about when to copy or not, and can always go back into
the Journal and resume an entry.  Maybe this is the wrong approach.
If we don't automatically copy for them, how do we expose that, make
them aware of it, and offer a simple way for them to do it?  Perhaps
an entry with an alias has a special button which pulls the aliased
content in upon request, automatically.

- Eben

PS. Please submit tickets for the feedback issues you see.  We need to
close up holes like that and make sure the laptop keeps the kids
properly informed about such things.



More information about the Devel mailing list