[Sugar-devel] Feature Freeze exception request: Journal Sort

[Tomeu Vizoso]

On Mon, Aug 23, 2010 at 18:08, Andrés Ambrois <andresambrois at gmail.com> wrote:
> On Monday, August 23, 2010 04:25:48 am Tomeu Vizoso wrote:
>> On Sat, Aug 21, 2010 at 01:24, Aleksey Lim <alsroot at member.fsf.org> wrote:
>> > Hi all,
>> >
>> > Implement sorting in the Journal UI. Also adds support for the two new
>> > properties (filesize and ctime).
>> >
>> > Feature page:
>> > http://wiki.sugarlabs.org/go/Features/Journal_Sort
>> >
>> > Implementations:
>> > http://git.sugarlabs.org/projects/sugar-datastore/repos/journal_sort
>> > http://git.sugarlabs.org/projects/sugar/repos/journal_sort
>>
>> Some questions:
>>
>> - what with hard links? Aren't users going to expect that if they
>> delete an entry of 50MB that their available space will be increased
>> by 50MB?
>
> One way or the other, we are going to leak the abstraction that different
> journal entries consume disk space independently; be it by the behavior you
> describe, or providing some sort of visual hints. I don't think there's much
> we can do except making it clear that file size is just a hint these days
> (think filesystem compression).

Sounds good.

>> - creation time will be always displayed as '%Y-%m-%dT%H:%M:%S' ? What
>> about those countries where they expect the fields being ordered in a
>> different way? (may be good to format the string in listview.py
>> instead of in listmodel.py, so we keep UI decisions out from the
>> model).
>
> I agree with that separation of concerns. In fact it was initially that way,
> but the format is required by activities such as Etoys, that break unless we
> use it. Other activities may also be depending on it, as it is documented in
> [0].

Fair enough.

>> - if we are not interested in sorting by title, we should remove that
>> field from the index, because makes the index bigger and also slows
>> queries down a bit.
>
> As I've learned from this work, adding/removing DS properties should be done
> with care, as everything can break in a gazillion ways. In any case, that
> belongs to a different patchset.

But you see that if we let patches come without asking the submitter
to counter any regressions in performance-critical areas then we'll
get inevitably slower and slower?

>> - seems like this feature is still in dicussion in
>> http://bugs.sugarlabs.org/ticket/1915 so I don't think it makes sense
>> to accept it for inclusion in 0.90 at this stage. Also would be good
>> to have the feature first accepted in the release set before
>> eventually merging it.
>
> It would be a shame for it to miss the boat, but I think that this should get
> plenty of testing as it may cause data loss for users.

In any case, I think we need to decide first of all what we want to
land with respect to the issues that Gary found.

Regards,

Tomeu

>> Regards,
>>
>> Tomeu
>>
>> > --
>> > Aleksey
>
> [0] http://wiki.sugarlabs.org/go/Development_Team/Low-
> level_Activity_API#Meta_Data
> --
>  -Andrés
>