Journal Suggestions

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eben Eliason wrote:
| On Tue, Apr 29, 2008 at 3:25 PM, James Simmons
| <jim.simmons at walgreens.com> wrote:
|>  Eben,
|>
|>  You bring up some points I hadn't considered.  I agree that thumb drives
|> and the like probably shouldn't have their files modified if all you are
|> doing is reading them.  By their nature these drives will be used to copy
|> files to and from non-Sugar systems, so leaving them alone makes sense.  On
|> the SD card, however, this is a different issue.  The SD card is
|> deliberately made difficult to remove.  If someone buys and installs an SD
|> card perhaps it should be considered a part of the Journal itself.  More
|> like buying a second hard drive for your system than plugging in something
|> removeable.  So now I have just one Journal with 2.5 gigs free instead of
|> 500 megs free.  That's the way I was hoping to use the SD card when I got
|> it.
|
| That's a very interesting idea, and one I'm quite happy to entertain.
| It seems on the surface like a very logical way to handle SD cards.
|
|>  As for thumb drives, not keeping metadata for stuff on these is OK as long
|> as the user interface does not suggest that you WILL keep metadata for
them.
|> Currently the Journal entry looks exactly the same for an item on a thumb
|> drive or SD card as it does for the Journal proper.  There is a place for a
|> screenshot, for notes, etc.  None of this works, but it suggests to the
user
|> that it *should* work.  That causes confusion.  At least I was
confused.  If
|> these non functional areas were hidden that would help.
|
| Agreed.  If you look through the mockups for the new designs, you'll
| see that external devices will actually be completely independent from
| the Journal UI.  They appear in the device tray, and when viewing one,
| you'll be in a list view that looks and functions similarly to the
| Journal, but should certainly take into account as you mention that
| tagging etc. isn't available on them, if that's the way we choose to
| go.

The logical conclusion, it seems to me, is that the datastore should support
1. Datastore-controlled devices with metadata
2. Non-datastore-controlled devices without metadata
3. Detection of whether a given device is type 1 or type 2.
4. Conversion of external devices from 2 -> 1 and 1 -> 2, only when
initiated by the user.
5. Using Type 1 devices to extend the capacity of the Datastore.

This means that:
If you put in a blank USB stick, it'll be recognized as a non-metadata
device and shown as such in the Journal.  The same is true of a blank SD
card.  If you hover over either device in the Journal, you can be
presented with an option like "Format this device as Advanced Storage".
This option would not destroy any data, or perform any actual low-level
formatting, but might well remove the directory structure and otherwise
shuffle things around.  If the user selects this option, then after the
conversion completes (it could be very fast), the device will instead show
an option "Extend my Journal onto this device".  The Type 1 vs. Type 2.
detection would presumably depend on the presence of something like
.olpc.store/

This approach also works well for accessing network shares, and doing
seamless backup to the school server, by representing SMB or NFS mounts as
Type 1 or Type 2 devices, depending on the presence (and correctness) of
.olpc.store/.  The school server would simply provide every student with
an NFS mount, or perhaps a more exotic networked filesystem, appropriately
configured as a Type 2 device.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIF34tUJT6e6HFtqQRApmbAJ4iWMg+g3oH2UrLuVXjOgYl17hltACfWAKZ
mT+amSKBAhvFtJy60cW5ojM=
=q57K
-----END PGP SIGNATURE-----