@jjazeix , @bcoudoin We can keep this thread for conversation and development.

Adding @hkaelberer

I made several changed to the documentation of this task. First the goal is really to save space and not to let the user download individual activities. Normal users don't care about that. Then I don't want to give the children the ability to un-download activities, again, the user don't care and children can't be exposed to a such feature. In replacement, I propose to manage this as a cache in which we will have to implement a reasonable cleanup based on the user activity usage.

Technically, I prefer that we keep the Download Manager scope as it is today, it downloads what we ask it to download, that's all. I introduce an Activity Downloader that know the dependencies of activities and drives the Download Manager accordingly.

I had some doubts, please clarify:

1. When we say, we would run a cleanup to remove unused activities, are we thinking something like a cron job that would check periodically for unused activities and remove them. In that case, we would also have to check if an activity is unused but is a dependency for some other activity, then we cannot remove it. So, is it possible to restructure all activities in such a way that no activity is dependent on any other activity, for eg. sat activity 'A' depends on activity 'B', then could we remove the concerned files/resources from B as well and make a separate directory which will now act as a dependency for both.
2. Additionally, we will also have to think of a time-period in which if an activity is unused it will be removed, such that this thing doesn't become annoying for the user. Or, we could also think of having a default time-period but also give user an option to change that if he/she want.
3. 'Avoid download of duplicate activity on the user end ' is being removed from task description, are we dropping it for now?
4. We are not giving children the option to remove an activity, but he/she could download a new activity not present locally, right?

When we say, we would run a cleanup to remove unused activities, are we thinking something like a cron job that would check periodically for unused activities and remove them.

I mention we can do this on start and stop. This is good enough.

In that case, we would also have to check if an activity is unused but is a dependency for some other activity, then we cannot remove it. So, is it possible to restructure all activities in such a way that no activity is dependent on any other activity, for eg. sat activity 'A' depends on activity 'B', then could we remove the concerned files/resources from B as well and make a separate directory which will now act as a dependency for both.

We don't need to restructure for this need, the cleanup algo can take that in account and not remove an unused activity if it is needed by a used one.

Additionally, we will also have to think of a time-period in which if an activity is unused it will be removed, such that this thing doesn't become annoying for the user. Or, we could also think of having a default time-period but also give user an option to change that if he/she want.

Yes for the "remove unused activity" we have to think about reasonable defaults.

'Avoid download of duplicate activity on the user end ' is being removed from task description, are we dropping it for now?

I don't understand what this means specifically, what is a duplicate activity. The system is a cache, either we have it locally and we don't download it, either we don't have it or not the last possible version and we download it.

We are not giving children the option to remove an activity, but he/she could download a new activity not present locally, right?

Yes and no, the children does not download an activity, she just enters in it and it is being downloaded. This download feature should be invisible to the user like your browser manages a cache of image locally. You don't want to tell your browser to dowload an image in the cache for future use. You just look at the image.

In T1943#25509, @bcoudoin wrote:

When we say, we would run a cleanup to remove unused activities, are we thinking something like a cron job that would check periodically for unused activities and remove them.

I mention we can do this on start and stop. This is good enough.

Yes, I don't like the idea of gcompris doing tasks periodically when not running :).

Additionally, we will also have to think of a time-period in which if an activity is unused it will be removed, such that this thing doesn't become annoying for the user. Or, we could also think of having a default time-period but also give user an option to change that if he/she want.

Yes for the "remove unused activity" we have to think about reasonable defaults.

I don't like of auto removing activities. For me it should be an user choice (probably in admin mode so children don't do it alone) and should not be automatic.

We are not giving children the option to remove an activity, but he/she could download a new activity not present locally, right?

Yes and no, the children does not download an activity, she just enters in it and it is being downloaded. This download feature should be invisible to the user like your browser manages a cache of image locally. You don't want to tell your browser to download an image in the cache for future use. You just look at the image.

On my side, I saw it more like a package manager, but in both case, we'll have a new use for the Loader item :).

In T1943#25510, @jjazeix wrote:

In T1943#25509, @bcoudoin wrote:

When we say, we would run a cleanup to remove unused activities, are we thinking something like a cron job that would check periodically for unused activities and remove them.

I mention we can do this on start and stop. This is good enough.

Yes, I don't like the idea of gcompris doing tasks periodically when not running :).

Additionally, we will also have to think of a time-period in which if an activity is unused it will be removed, such that this thing doesn't become annoying for the user. Or, we could also think of having a default time-period but also give user an option to change that if he/she want.

Yes for the "remove unused activity" we have to think about reasonable defaults.

I don't like of auto removing activities. For me it should be an user choice (probably in admin mode so children don't do it alone) and should not be automatic.

I agree.

At least should the user have the opportunity to tell the app to not delete automatically what he has already downloaded.

Although we have to consider that a child is not an adult user and more automatism is appropriate. Must be weighted up against wasting resources.

We are not giving children the option to remove an activity, but he/she could download a new activity not present locally, right?

Yes and no, the children does not download an activity, she just enters in it and it is being downloaded. This download feature should be invisible to the user like your browser manages a cache of image locally. You don't want to tell your browser to download an image in the cache for future use. You just look at the image.

On my side, I saw it more like a package manager, but in both case, we'll have a new use for the Loader item :).

Agree. We must take care to not waste resources, especially on cellular networks where (at least in Germany) flatrates are limited and MB are spared. It may also become annoying if starting an activity takes too long (consider a cellular 2G connection) without telling the user why it takes so long ("Downloading ...")

BTW. iirc the Bearer Managment support was added in the meanwhile for Android. If so, we could reconsider to allow for a more fine grained control of automatic downloads with respect to network connectivity (Cellular vs. Wifi/LAN).

Besides:

• I support the idea to not overload DownloadManager with much additional functions and move activity managment to a dedicated module. Real support for parallel downloads might be worth adding, though. The infrastructure is there but not in all places (especially the signals).

• What about the idea from the old mail thread: to always ship a mininum amount of activities to not let the user install a naked app only? Maybe the free activities?

PS: Can't I simply reply to the notification mails of phabricator comments and let phabricator insert the comments automatically?

Le 30/03/2016 14:27, hkaelberer (Holger Kaelberer) a écrit :

hkaelberer added a comment.

> 
> 
>>>   We are not giving children the option to remove an activity, but he/she could download a new activity not present locally, right?
>> 
>> Yes and no, the children does not download an activity, she just enters in it and it is being downloaded. This download feature should be invisible to the user like your browser manages a cache of image locally. You don't want to tell your browser to download an image in the cache for future use. You just look at the image.
> 
> On my side, I saw it more like a package manager, but in both case, we'll have a new use for the Loader item :).

Agree. We must take care to not waste resources, especially on cellular networks where (at least in Germany) flatrates are limited and MB are spared. It may also become annoying if starting an activity takes too long (consider a cellular 2G connection) without telling the user why it takes so long ("Downloading ...")

BTW. iirc the Bearer Managment support was added in the meanwhile for Android. If so, we could reconsider to allow for a more fine grained control of automatic downloads with respect to network connectivity (Cellular vs. Wifi/LAN).

We can consider this but the use case for GCompris is mostly dedicated
to tablets which are mostly WiFi based. Just checked the stats and I
don't have in the store precise numbers on that. It shows clearly that
there is no phones in the top users.

  Besides:

- I support the idea to not overload DownloadManager with much additional functions and move activity managment to a dedicated module. Real support for parallel downloads might be worth adding, though. The infrastructure is there but not in all places (especially the signals).

- What about the idea from the old mail thread: to always ship a mininum amount of activities to not let the user install a naked app only? Maybe the free activities?

Yes, this is a deployment option. This development must take in account
that some activities are pre-shipped. This maybe annoying because this
means activities pre-shipped cannot be erased, just overloaded by a new
download in the cache directory. So maybe a good option is to provide a
download option when first starting GCompris like "Download activities
for 2-4 years old", "for 5-7", "for 8 and above", "None (on demand)".

PS: Can't I simply reply to the notification mails of phabricator comments and let phabricator insert the comments automatically?

Let's try, I answer from Thunderbird.

Although this couldn't get selected for GSoC'16, I would still like to do this.
However, seeing the nature of the project I would be needing a mentor. Please tell me if that's possible.

Sure you can work on it. If you have issues feel free to ask either here, on irc or on mailing list.

@jjazeix , @bcoudoin I would like to do this task under season of KDE 2016-2017.
Here's my repo for proposal sok_proposal .
Please review and comment if it's ok , so that i can submit the proposal
Thanks

Hi @shashwatdixit I was occupied a bit lately. But I've resumed the task as for now.
Still @jjazeix is the best person to ask to, whether or not he thinks it is better to take it under SoK

Hi @shashwatdixit, if @skat00sh is working on it we should let him. If for any reason he can't work on it anymore, he'll release the task

@skat00sh hi, do you have any news on this one? It may not impact the next release but it will probably be impacting the one after so it would be best to release the task if you don't work on it so any other interested person can work on it if needed.

After lot of thinking, I really think we should not do this.

It would make the system quite complex for not much benefit in the end... The full application size is already not very big, I don't think making it smaller would be really useful.

Maintaining the extra data downloads is already not so easy in several ways, I'm sure that if we make activities downloadable like this it would become insanely complex to maintain in the long term.
(making sure activities work across versions, depending on gcompris code and Qt version used...)

I would vote for closing this task as Wontfix.