[GCompris-devel] Plugin system for rcc

[Holger Kaelberer]

Hi,

some thoughts:

On 23.09.2015 01:56, Bruno Coudoin wrote:
>
>
> Le 22/09/2015 00:02, smirnoff.al at gmail.com a écrit :
>> IMHO, the matter the fact, that GCompris loads languages and  other resources direct from internet is quite unusual for kde application.
>
> Hi,
>
> Sure, we don't plan to change the way GCompris will be packaged on
> GNU/Linux. We are looking at the specific issues that comes from the
> mobile world and that we have to address.
>
> We won't find a universal solution to this anyway and we have to be
> flexible enough to handle the different types of installations. We could
> try to categorize the different use cases :
>
> - desktop: we already support this
> - mobile (disk constrained): where to draw the line between shipped
> content and online one and how to maintain the online side.

- One possibility for 'the line drawn' was already mentioned: Ship everything that is included qua 
part of the demo version and make downloadable what is only part of the in-app purchased 'full' version.

- I agree with Johnny, that we should ship some activities, so that the user can get some idea of 
what it is about. If I, as a user, would install something from the play store that provides only 
the bare executable without any activities, I would uninstall it again right away.

- Maintain the online activities: As Johnny said already, we'd need more metadata (than the current 
Contents file), to allow the user to select between the available activities.

For the status quo (i.e. regarding all activities we have currently in GCompris) we have several 
options, let me name two:

1. Keep minimal information about downloadable activities also packaged, to be able to present an 
overview of what there is available for download. 'Minimum' might then mean per activity 
ActivityInfo.qml + <activity>.svg. This would even allow to present the user a complete menu with 
the option to provide a 'u wanna download'-dialog when an activity is selected. (What we discussed 
at Randa, Bruno). Upstream/online we'd hold the complete rcc, that would be downloaded an registered 
on demand.

2. Have no information about downloadable-only activities packaged and provide them only online as a 
kind of a more complex 'Contents' directory, maybe providing the minimal information from 1. This 
would mean that a user *must* have online access even for seeing what there is available. This has 
the charm of being completely independent of the base application and could also be used as kind of 
a 'GCompris activity store' (you named it, Johnny ;-) which could be filled and extended 
independently of the base application shipped in the play store. This goes a bit beyond our current 
requirements, though.

For both options we'd probably need to maintain some core API versioning PLUS make activities define 
min (and max?) required API versions. Even for a scenario like 1. you can easily imagine cases that 
would lead to runtime errors (like new activities are put online and an old version of the GCompris 
app tries to download them. Or: we change the core API in a non-backward compatible way -> old 
activities already downloaded don't run in new version of the base application.)

> - offline (may be mobile, desktop or kiosk): need to provide a way to
> provide a dataset even for mobile users having no net access.

- Online full version: Kind of a full package for the target platforms in question. What about 
defining your 'full version' on the app store like that, Bruno? I know Android is somehow 'bound' to 
Google's play store, but let me just raise the question of whether there are no alternatives to this 
company's commercial distribution system with its strange constraints? Personally I've never used 
another android store, although I often install apk from other sources. For special use cases (like 
maybe school environments) it might be an option to simply install a full apk from gcompris.net or 
so and thus become more independent of foreign contraints.

No idea, how things work (or don't work) for ios mobile devices.

- Offline installation: Besides directly *installing* a full package, one could also directly copy 
actvities onto the devices. We already support such a manual install directory for the voices meant 
for copying directly an rcc-file via USB or so to be read by DownloadManager. Like that we could 
also support manual installations of activity rcc-files.

>
> We also have to consider the update scenarios, either full application
> or only activities.

Good point and kind of an extension of the current requirements for size limitations of mobile 
packages. As for above 2. some kind of API compatibility checks would be necessary for that. Maybe 
only by maintaining different activties/<api-version>/-directories upstream.

Holger

>
> I don't have the solution, just trying to clarify our needs.
>
> Bruno.
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel
>