[Sugar-devel] How to copy something from the Journal to a pendrive? FotoToon export?

[tom.staubitz at fhtw-berlin.de]

On Oct 17, 2010, at 1:54 PM, Sascha Silbe wrote:

> Excerpts from tom.staubitz at fhtw-berlin.de's message of Sun Oct 17 09:02:42 +0200 2010:
> 
>> Imagine two or more children. Half of them are in country1, the others are in country2.
>> They would like to collaborate on an activity, e.g. FotoToon.
>> One of the groups starts and adds a picture and some bubbles. Now they want to send their work to the other group so that they can add a picture and a couple of bubbles. This goes back and forth a couple of times. 
> 
> Re-reading your post again, it seems what you actually wanted to do was
> to save an activity _session_ (the content you worked on), not the
> activity itself (the program).
Exactly. 

> This is still a bit of a sour spot. In order for the system to know what
> activity it needs to know either the activity it has been previously
> opened with or the MIME type (so it can select activities that are able
> to handle this type - that's what the "Start with" submenu shows).
> The Sugar data store can store metadata as arbitrary key=value pairs.
> Activities use this to set the activity id and the MIME type of the
> entry, so the Journal can resume an entry fine as long as it's in the
> data store and the metadata is preserved.
> 
> External storage media (USB sticks, SD cards) are intended as a means
> to interchange data with non-Sugar systems, so we store entries as plain
> files instead of putting a data store on them (that no non-Sugar system
> would be able to read). And here we enter the messy world of traditional
> desktop systems: there is no place (*) to store metadata, especially not
> non-standard properties like the activity that wrote the entry. Not even
> the MIME type can be preserved properly; we need to rely on mappings
> between file extensions and MIME type. There's no single, central
> mapping (except for a few standard types) but rather each application
> ships a small part of the database with the MIME types and file
> extensions it cares about. If you don't have an application installed
> that recognises the file extension, you won't know the MIME type.

So what would be the right medium to interchange data between Sugar systems?

> The same technology is used in Sugar for reading files on external
> media. So if an activity wants to handle files of a certain MIME type,
> it needs to tell Sugar how to recognise the files (by shipping a
> suitable mimetypes.xml [1]). This is what some of the activities use
> to make the data store <-> USB stick <-> data store roundtrip work:
> They choose a custom MIME type and file extension. When copying files
> to the USB stick, the Journal will set the file extension based on the
> MIME type. When copying the entry back from the USB stick, the Journal
> will map the file extension back to the MIME type (if the activity is
> installed, i.e. if the mimetypes.xml is present). If the activity tells
> Sugar it can handle entries of this type (by setting mime_types in
> activity.info [2]), it will be used for opening (resuming) the entries.

Does this mean that in the FotoToon example I could manually add a mimetypes.xml
to the .zip file, remove the zip extension and FotoToon should be able to recognize this again?

> There is a way to transfer a data store entry including all of its
> metadata: Journal Entry Bundles [3]. Unfortunately the only way (that I
> know of) to _create_ such a bundle is my Backup activity [4] and it
> stores the entire data store instead of a single entry.

Would the copy-from-journal / copy-to-journal scripts do the trick?

> It also uses a
> different MIME type and file extension (to make sure that these bundles
> are handled by the Restore activity [5] which can cope with JEBs
> containing multiple entries, unlike the Journal) but that would be easy
> enough to work around (by renaming the file).

But it would mean that if I'm doing a Backup on User1's XO and doing a Restore on User2's XO, User2's data is lost and she's got all the stuff from User1 in her journal, right? 

> Thanks for following me through to the end. ;)

Thanks for the detailed information.

> Sascha
> 
> (*) There are extended attributes [6], but they are only supported on
>    some file systems (in particular not on VFAT, which is what all the
>    USB sticks and SD cards come pre-formatted as) and need to be
>    enabled explicitly (in /etc/fstab; no idea if it's possible to tell
>    the Gnome auto mount magic to do it). Except for OS/2, Mac OS and
>    a few special applications I don't know of anything that actually
>    uses them for metadata (i.e. MIME type & co).
> [1] https://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles#Bundle_structure
> [2] https://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles#.info_file_format
> [3] http://wiki.laptop.org/go/Journal_entry_bundles
> [4] http://activities.sugarlabs.org/en-US/sugar/addon/4326
> [5] http://activities.sugarlabs.org/en-US/sugar/addon/4327
> [6] http://en.wikipedia.org/wiki/Extended_attributes
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel