Re: [Sugar-devel] SD card / USB stick support (was: Re: [IAEP] Project Gutenberg, etc.)
On Thu, Apr 30, 2009 at 09:50, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Following up on a discussion on iaep... On Wed, Apr 29, 2009 at 04:10:59PM -0500, James Simmons wrote: The SD card cannot do everything the Journal can do, [...] This is something that we should fix. The way the SD card / USB stick support works (in Sugar 0.82.1 on the XO) has bugged me for the past few days (e.g. only FAT filesystems will be usable from inside the Journal). Maybe it could work roughly like the following (just a brain dump): - automount everything, with UUID-based access (/media/by-uuid/uuid) in addition to the current name-based access (/media/name[_increment]) - use flag files (empty file with well-known name, e.g. .sugar_datastore_ignore) on the filesystem to filter it out from the Journal (so it doesn't index/show the wwwoffle cache) - let the user unmount Journal-monitored filesystems from the command line (regular umount doesn't work because the fs is busy) This way SD cards and USB sticks can be used as both a Journal expansion and low-level storage expansion (using symlinks to /media/by-uuid/...), even in parallel (on the same device). This has changed quite a bit in 0.84. Removable devices can be mounted regardless of the filesystem in them, but no metadata will be saved on the device because we don't write anything else there. Also queries will be slower because we don't have a database with file data indexed. The simplest solution would be to provide a view in the journal that is more clearly a file system layout. If we had the journal split in action and object views, removable devices wouldn't have action views and the object views would display the dir hierarchy. If we want the removable device to behave like one more journal, we'll need to store a database there. The problem is that people use to yank these devices before all data has been written, thus corrupting these data structures. Regards, Tomeu [book reading activity] [...] it would store meta info for the books, as well as the content type of the book (which the MIME type by itself would not be enough to do). What do you mean with content type if the MIME type is not enough (but apparently closely related)? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJ+Vg5AAoJELpz82VMF3DawB0H/0XfKa3YT1qwoLSJgTZd6GNU 8cC30bkkvyfNPvmbehB0zhhy/fe2AIPbSjqbEQROskKvsSi89tf7Kxhw5FNwyzmy yG9s9rgDgCtBAFhUfyY9vTX3Q9dqtt/kGsBWlL5oZ/iUeRUuKZBQIZyHmTA2PkDp dGXEomn5FddbjDmWOHDQfT+zOZJPqhB/PH3ZF7Ug3Cz9VXGooiH/k0tAr02aEKX9 HgnQ71kbo1dXx5tAiXYSSb6QBKoXWhkTKLS6WR9pIjf+HRQVUDhbLFphEHe7SRxz A0yf7ddiPw437e/FaGLoz7pcY8gw6tkrLhybSwAsADu1RKkA6WK1tHx+xs7cGB8= =ev0l -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SD card / USB stick support
Sascha, In regard to my comment: [...] it would store meta info for the books, as well as the content type of the book (which the MIME type by itself would not be enough to do). what I meant was that there are some MIME types mapped to more than one Activity. For instance, the MIME type text/plain is used by Read Etexts but also by the Write activity. application/zip is used by Etoys, View Slides, and Read Etexts. Because of this you cannot simply click on an entry in the Journal that has one of these MIME types to resume it. You need to specify which Activity you want to open it with. You need to do this every single time, and it's annoying. The real answer to this is not what I talked about in that email. The real answer is to implement Unified Bundles which package books up like Activities and have a configuration file that says how they should be opened: as a bunch of images in a Zip file, as a plain text file, etc. That way when I try to read a Gutenberg text file I don't have to deal with opening Write by mistake, and when I'm viewing a comic book I don't have to deal with opening Etoys by mistake. Journal entries created by an Activity are always resumed by that Activity. It's the Activities that DON'T create their own Journal entries that have this issue. This problem makes Sugar less usable as a platform for reading ebooks, which is a shame because ebook reading could be a killer app for Sugar and the XO otherwise. Unified Bundles were proposed a couple of weeks ago as a way of dealing with these problems and others. I regards to your point on the SD card, I would love for it to act as a second Journal. Failing that, it should have a view in the Journal that communicates to the user that it is NOT a second Journal. Maybe a Windows Explorer kind of view that shows subdirectories, etc. The current situation where it LOOKS like a Journal but doesn't ACT like one (no metadata saved, etc.) is annoying. And whatever you do with the SD card the USB thumb drive should definitely have an Explorer look and feel. It is something foreign to Sugar and it should look that way. James Simmons Sascha Silbe wrote: Following up on a discussion on iaep... On Wed, Apr 29, 2009 at 04:10:59PM -0500, James Simmons wrote: The SD card cannot do everything the Journal can do, [...] This is something that we should fix. The way the SD card / USB stick support works (in Sugar 0.82.1 on the XO) has bugged me for the past few days (e.g. only FAT filesystems will be usable from inside the Journal). Maybe it could work roughly like the following (just a brain dump): - automount everything, with UUID-based access (/media/by-uuid/uuid) in addition to the current name-based access (/media/name[_increment]) - use flag files (empty file with well-known name, e.g. .sugar_datastore_ignore) on the filesystem to filter it out from the Journal (so it doesn't index/show the wwwoffle cache) - let the user unmount Journal-monitored filesystems from the command line (regular umount doesn't work because the fs is busy) This way SD cards and USB sticks can be used as both a Journal expansion and low-level storage expansion (using symlinks to /media/by-uuid/...), even in parallel (on the same device). [book reading activity] [...] it would store meta info for the books, as well as the content type of the book (which the MIME type by itself would not be enough to do). What do you mean with content type if the MIME type is not enough (but apparently closely related)? CU Sascha ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SD card / USB stick support (was: Re: [IAEP] Project Gutenberg, etc.)
Following up on a discussion on iaep... On Wed, Apr 29, 2009 at 04:10:59PM -0500, James Simmons wrote: The SD card cannot do everything the Journal can do, [...] This is something that we should fix. The way the SD card / USB stick support works (in Sugar 0.82.1 on the XO) has bugged me for the past few days (e.g. only FAT filesystems will be usable from inside the Journal). Maybe it could work roughly like the following (just a brain dump): - automount everything, with UUID-based access (/media/by-uuid/uuid) in addition to the current name-based access (/media/name[_increment]) - use flag files (empty file with well-known name, e.g. .sugar_datastore_ignore) on the filesystem to filter it out from the Journal (so it doesn't index/show the wwwoffle cache) - let the user unmount Journal-monitored filesystems from the command line (regular umount doesn't work because the fs is busy) This way SD cards and USB sticks can be used as both a Journal expansion and low-level storage expansion (using symlinks to /media/by-uuid/...), even in parallel (on the same device). [book reading activity] [...] it would store meta info for the books, as well as the content type of the book (which the MIME type by itself would not be enough to do). What do you mean with content type if the MIME type is not enough (but apparently closely related)? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
