[Sugar-devel] [PATCH] Convert Journal entries that have been saved to a storage device in 0.82

[Simon Schampijer]

On 02/19/2011 02:13 PM, Sascha Silbe wrote:
> Excerpts from Simon Schampijer's message of Mon Feb 14 23:04:42 +0100 2011:
>
[...]
>
> So this gets triggered as soon as somebody inserts a USB stick and will
> scan all entries in one go, blocking the UI? I'm a bit worried about
> response time for media with a lot of entries written by 0.82,
> especially since we do it over and over again.

 From my testing it is ok time wise.

> We could do it similar to how the data store does it: One entry at a
> time, returning True (=>  call again) unless we're done. We'd have to
> block (show the progress bar) when the user tries to show the contents
> before we're done with the conversion.
>
> An alternative would be to trigger it only once the user tries to list
> the contents, integrating it with the existing progress bar. I guess
> it wouldn't make much of a difference for the code (we'd still need to
> process only small chunks so the progress bar can keep going). The real
> issue is whether we do it in the background or in the foreground. If we
> do it in the background and the user does something else while we
> convert the entry, the response to switch the view to the medium will
> be much faster. OTOH if we do it in the foreground the user has a better
> chance of noticing there's something being done every time and can
> delete the 0.82 files.
>
> BTW, why don't we rename the 0.82 files after we finished the
> conversion? That way we don't need to do it over and over again. And if
> we really discover a bug in the conversion, we can just check for the
> renamed file, redo the conversion and rename to yet another name.

In a previous implementation I did write a file that indicated that the 
conversion did happen, so that the conversion would only happen once. 
The issue with that is the following:

Scenario A (backup): Teacher goes to machine A and copies items to the 
stick. The machine then gets updated and the items get copied to the 
Journal again. Now the teacher goes to machine B and insert the stick 
and copies entries to the stick. After the machine B is updated the 
stick is inserted. The items are not converted since the 'conversion 
file' has been written in machine A and can not be accessed.

So handling all those cases get quickly complicated. In the current 
approach the conversion does only happen once the stick is inserted not 
when listing the content, so I think it is ok that way. From testing, 
Sam was happy with the performance and the work flow.

In general, we should not make this code too complicated and invest too 
much time in performance tuning. I think the cases where someone wants 
to update Journal entries from pre-0.84 in 0.92 won't be too many. I 
think we can even mark that code as being deprecated soon.

Regards,
    Simon