The next file format

[Andreas Xavier]

---- On Tue, 26 Aug 2014 16:54:30 -0700 Bruno Coudoin 
 wrote ---- 

>
>Le 26/08/2014 21:51, Andreas Xavier a écrit : 
>> Hello Bruno, 
>> 
>> It looks like gcompris is looking for a common method to store 
>> semantically disparate resources to provide a uniform interface to 
>> the activities resources and common distribution. Judging only 
>> from the resources that are designated qrc:/location, you will be 
>> storing activity backgrounds and source code files etc. 
...

>Well, what you saw are the activity themselves. Each one is bundled in 
>an rcc file that contains a manifest (ActivityInfo.qml) a set of qml, 
>javascript, image and audio file. They are then loaded by the GCompris 
>binary at runtime. On Linux with the 79 activities the GCompris binary 
>is only 300KB and we have 79 rcc for each activities that takes 19MB. 
>BTW, these activity rcc could easily be distributed through a web server 
>either for updates or for the initial version. We could bypass the 'slow 
>update' cycle of linux distributions but this is another story. 

You may be looking for.

http://api.kde.org/frameworks-api/frameworks5-apidocs/knewstuff/html/index.html


>You can take 'missing letter' as an example but I like this one which is 
>more javascript than json: 
>https://git-next.kde.org/kde/gcompris/blob/master/src/activities/memory-wordnumber/dataset.js 
>

Thank you, if we get as far as integration of the library with gcompris
, then I will use memory-wordnumber as the test case.
 

>>> Some feedback on your proposal, I am confused by the 'confidence level'. 
>>> If it is a student mark, it may not be desirable to put it in the 
>>> dataset itself because it make sense to have it on a read only storage 
>>> area (most distros will do that). On this topic at GCompris we are 
>>> interested in a teacher specific tool to help them in their daily usage, 
>>> we starting specifying it there : 
>>> http://gcompris.net/wiki/Administration_design 
>>> 
>> I think Inge explained this elsewhere but I will elaborate. We plan to overlay 
>> files to allow vocabulary building, lesson planning and training to be 
>> separate stages. A single user might most conveniently use a monolithic file for all stages. 
>> But in other contexts a student might reference read-only files for different sections 
>> of the data. For example this overlay stack: 
>> 
>> (Words and Grammer) Read - Only, system file 
>> (Course Plan) Read - Only, different source, perhaps teacher editable 
>> (Student Goals and Training Data) Editable per user. 
>> 
>> 
>I share your concern here. It is true that it may be desirable to have a 
>dataset with content, voices, images and a dataset with a course plan 
>that references the data in the first one. Is this what you have in mind? 
>

Yes.  

For referencing content across multiple files, CoLa has already suggested ids of the form,
org.kde.edu.$COLLECTION.$UUID
Perhaps we could generalize them to, 
org.kde.edu.$COLLECTION.$UUID to provide better orientation within the file.


 
>Bruno. 
> 
>_______________________________________________ 
>kde-edu mailing list 
>kde-edu at mail.kde.org 
>https://mail.kde.org/mailman/listinfo/kde-edu 
>