-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eben Eliason wrote: | On Tue, Apr 29, 2008 at 3:25 PM, James Simmons | <[EMAIL PROTECTED]> 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----- _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
