Journal Suggestions

[Eben Eliason]

On Tue, Apr 29, 2008 at 3:59 PM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> -----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.

Well, there seems to be two ways to treat a device of type 1.  One is
to treat it as an independent entity, which happens to be "Journaled"
(has metadata, index, etc).  The device could still be treated as an
independent storage space, and it would be necessary for the user to
manually determine which files went onto it vs. into the Journal.  It
would give them, effectively, two separate Journals.

Another way to treat a type 1 device is as an extension of the NAND.
In this scenario, such as was suggested with the SD card initially,
all of the available space would be effectively made part of the
Journal.  Looking at the capacity meter for the Journal in the Frame
would indicate 2.5 GB instead of 500MB, and the device icon itself
would have some special treatment indicating that this is No Ordinary
Device.  In this model, the user wouldn't need to consider that there
are actually two physical places for storage; copying anything to the
Journal could silently place it in the other type 1 device which is
"extending" the Journal's space.  Of course, this also poses some
complex problems for what to do when such a device is removed, since
it effectively separates ones Journal into two pieces, and perhaps for
that reason alone, ignoring technical concerns, it should be
immediately forgotten that I brought this other approach up.

If this is in any way feasible, perhaps it does only make sense for SD
cards which can be physically installed in the machine at all times,
unlike the USB drives which are very much a peripheral instead.  In
the context of the XOs, this is almost the defining differentiator for
the two media.  The SD is inherently more "permanent".  It still seems
prudent to give the user the option to choose whether or not to make
an SD card a type 1 device anyway, of course.

- Eben