Appdownloader – the next steps
I was asked about giving an update on the status of the appdownloader, what is planned in the near future or has been changed already. Besides the bugfixes and small enhancements, like saving the user-credentials, some bigger improvement-ideas came up during the summer. Most of it is in proto-type stage, but once implemented properly it might add some value to the application itself and the process of downloading and installing applications on Fremantle.
OCS-compliant backend implementation
At the KDE Akademy in Tampere, we had a good talk about improvements in the OCS REST API. When we started with the server-side implementation of the application, we took the open-collaboration-services into use and we adopted it to our needs. The same did another project around MeeGo, so that we met in Tampere to to find a solution to this and to get our changes upstream. We had a really good discussion and at the end it seemed, that everybody was satisfied. What a rare situation Now we are going to change to that new API. The server-side is almost ready, but the client-side would need to be adopted to the new API. This is the first goal.
Changing the library
One possible idea would be to change to the libattica library, so that we could contribute to the OCS project even more, than API discussions. This would bring more stability in parsing of the xml content and further on the client side, as we would have to go along the standard the whole way.
The installation part should be made easier and faster as well, ideally without being tight to the Application Manager and the slow updating process of apt. The idea is a slight change in apt itself. Initiated by Marius Vollmer (apt-side) and with the help of Niels Breet (server-side), we are working on a way to speed up the update of the repository for apt. The idea is simple. Instead of making apt download, extract and work on the whole packages file, the idea is to get just that part of the repository that is necessary and useful from the user’s perspective. This information would be offered by another REST API on the server. The scenario, step-by-step:
1. Browse the applications by browsing them through the appdownloader.
2. Once you have clicked on an application to be installed, the appdownloader saves the application name, and sends it with all stored application-names to the server
3. The server creates an optimised list of the meta-data of the requested applications and further of all applications, which are in any relation to them (dependencies, conflicts, etc).
4. For the modified apt, this information will be enough to download the packages accordingly and resolve the dependencies.
Starting from there, it should help to improve things, like installation of more then one package at a time, speeding up the discovery and installation of packages, etc.. This would give the appdownloader as well some more meaning than just being another front-end for the content you can get anyway on the web-site.
I think all three steps are important. The first two ones for a seamlessly functional application and the latter one for improvements in the installation process. Goal is to have some proto-type, based on x-apt as soon as possible. But feel free to discuss the ideas and come up with further suggestions.