On Wed, Apr 30, 2008 at 10:15 AM, James Simmons <[EMAIL PROTECTED]> 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. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel