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.

Installation

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.

8 0

• browse throughout all the existing open source code of Diablo, Fremantle, Qt and more
• search by keywords in the code
• click and browse through references of functions, classes and parameters

All that is done with a consistent and intuitive UI. To understand, how powerful the tool really is, and how it can help you understanding parts of the platform, please visit http://mxr.maemo.org and try it out. Play a little bit around and let us know, what you think about it. The index for Fremantle is based on debian packages. A version for MeeGo, based on the sources in gitorious and rpm is being tested right now. Please follow further announcements on that, to be able to use it from the very beginning. For further questions don’t hesitate to ask “timeless” in the #maemo or #meego channel on IRC.

8 0

Packaging guidelines

22 0