Change Details

We need to change the way of storing rcc to cache the files in the server. Proposed solution: * Version the rcc files with the hash (or unique identifier like the date): voices-ogg.rcc would become voices-ogg-${hash}.rcc ~~* When generating the rcc, have the voices-ogg.rcc be a symbolic link to voices-ogg-${hash}.rcc~~ ~~* When generating the Contents file, use the short names (so without hashes).~~ * When generating the Contents file, use the full names (but don't create a Contents-${hash} file, only a Contents file). * In the application, read the files from the Contents file, using the locale. * Create a data3 folder in the server to put the new files. ~~This way, we don't need to change anything on application side.~~ For the legacy versions, we will still need to generate the short paths, put them in the data2/ folder, and ask for a refresh of the CDN cache to the sysadmins. We can keep this in a separate branch and cherry-pick from master of gcompris-data all the voices changes.

We need to change the way of storing rcc to cache the files in the server. Proposed solution: * Version the rcc files with the hash (or unique identifier like the date): voices-ogg.rcc would become voices-ogg-${hash}.rcc ~~* When generating the rcc, have the voices-ogg.rcc be a symbolic link to voices-ogg-${hash}.rcc~~ ~~* When generating the Contents file, use the short names (so without hashes).~~ * When generating the Contents file, use the full names (but don't create a Contents-${hash} file, only a Contents file). * In the application, read the files from the Contents file, using the locale and force to look in data3/ folder. * Create a data3 folder in the server to put the new files. ~~This way, we don't need to change anything on application side.~~ For the legacy versions, we will still need to generate the short paths, put them in the data2/ folder, and ask for a refresh of the CDN cache to the sysadmins. We can keep this in a separate branch and cherry-pick from master of gcompris-data all the voices changes.

We need to change the way of storing rcc to cache the files in the server. Proposed solution: * Version the rcc files with the hash (or unique identifier like the date): voices-ogg.rcc would become voices-ogg-${hash}.rcc ~~* When generating the rcc, have the voices-ogg.rcc be a symbolic link to voices-ogg-${hash}.rcc~~ ~~* When generating the Contents file, use the short names (so without hashes).~~ * When generating the Contents file, use the full names (but don't create a Contents-${hash} file, only a Contents file). * In the application, read the files from the Contents file, using the locale and force to look in data3/ folder. * Create a data3 folder in the server to put the new files. ~~This way, we don't need to change anything on application side.~~ For the legacy versions, we will still need to generate the short paths, put them in the data2/ folder, and ask for a refresh of the CDN cache to the sysadmins. We can keep this in a separate branch and cherry-pick from master of gcompris-data all the voices changes.