[Sugar-devel] [PATCH] Share Journal entries over external devices #1636

[Simon Schampijer]

On 11/26/2010 04:33 PM, Sascha Silbe wrote:
> Excerpts from simon's message of Thu Nov 25 10:51:16 +0100 2010:
>
>> metadata and preview of an entry are stored in hidden files. For example
>> when copying an entry homework.pdf to the device a file called
>> .homework.pdf.metadata and .homework.pdf.preview will be stored on the
>> device as well. Those will be read in when copying an entry from the
>> external device to a Journal.
>
> I'm not yet convinced of that approach. How do you detect and handle
> "stale" metadata and preview files? Especially since you "hide" the
> files (how do non-Unix OSs handle dot-files, BTW?) they will not get
> deleted together with the data file. Any file created later (from
> outside of Sugar) with the same name will suddenly have metadata that
> the user never intended it to have.

Another approach was to use JEBs [1]. This would pack it all in one 
archive, so only one file needed. It handles fine the Journal-to-Journal 
case. The downside is that you can not easily open it on another machine 
until you unzip it first. I am a bit torn what I like more.

[1] http://wiki.laptop.org/go/Journal_entry_bundles

>> The approach has been discussed in the ticket #1636 and has been reviewed.
>
> I missed that discussion because it happened on Trac. Please, let's have
> all engineering discussions on sugar-devel where everybody can follow
> them.
>
>> This patch should go into master and 0.90 to allow for an update from
>> 0.84 to 0.90.
>
> I'm not sure we should really do non-bugfix changes to 0.90. Downstream
> is welcome to cherry-pick everything they like from master, of course.

I think it is dependent on the case. If we land a fix like this in 0.84 
we need to make sure that our users have the same functionality in 0.90. 
Of course we can patch 0.90 but other packagers might profit of this, 
too. Not sure what dextrose want to do about that issue for example. But 
of course the general rule is to only do bug fixes to a released version.

Thanks for the other code based comments. As this is an important issue 
that we will have to deal with for a bit longer would be nice to get an 
agreement on the approach, that we do not have to change it again in the 
near future.

Regards,
    Simon