NAND Full Requirement

[Eben Eliason]

I'm skeptical about how well this will work in practice.  In our initial
discussions of a heuristic for deciding what the Journal /recommends/ for
deletion (note, it doesn't have to automatically delete without consent, per
se), we thought that activities should be extremely low on the list, based
on the fact that it's not possible to resume old entries created with them
once they are gone.  Perhaps we could also determine how many of those kinds
of dependent entries exist as well, and use that as part of the heuristic.
Nonetheless, it also doesn't help our cause much if we say "we can delete X
because the kid can get it back", because that will just fill up the space
all over again, which defeats the purpose.  I'm not arguing that this isn't
a reasonable idea, of course -- it seems to be the case that kids /do/
actually download lots of activities to try (many more than we anticipated),
and may use many of them just once or a few times.  I'm merely pointing out
that, in order for this to actually help in this situation, we need to be a
bit smarter about how we decide which activities can go without the kid
caring and with minimal future impact.

- Eben


On Tue, Jul 22, 2008 at 5:01 PM, Mikus Grinbergs <mikus at bga.com> wrote:

> This is not meant as an implementation suggestion, but as a
> philosophy-of-purging comment:
>
> Greg listed some requirements, among them:
> > - Must not disable any activities or other functionality
>
> The discussion mentioned that in Uruguay it was precisely
> 'Activities' that often filled the NAND.  To me, an 'Activity' is
> something static - if a kid could obtain it once, he can probably
> obtain it again.  As such, I think in the case of a full NAND,
> database entries showing the __fetching__ of Activities would be
> ideal for "automatic deletion".  To minimize the impact on the kid,
> don't delete these kinds of entries for his 'favorite' Activities.
>
> mikus
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080722/d36637a2/attachment.html>