-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just to give some more meat/background to the discussion, here are the ideas that lead us (Benjamin Weber and I) to implement the Software Portal (http://software.opensuse-community.org): 1) Applications - --------------- Newbies shouldn't be exposed to "packages" and only to a very limited extent to repositories, but, rather, to "applications". That means that they should be able to search for "firefox" or "amarok" in a central place and be able to install it easily from there. No libraries, no development packages, and applications being bundles of 1-n packages. Tagging is obviously a very useful tool for navigation as well, as people might just want to look for "games" or "email" instead of having to know the name of the packages/applications. 2) Web-based - ------------ The idea was also to have them use their web-browser to search and install stuff, as that is what most people just do. OneClickInstall (which was originally written by Benjamin Weber too) is used to trigger the package installation when they click on an "install" button. For those who don't know, it's implemented through the MIME type and handlers in the openSUSE packages of Firefox and Konqueror (as opposed to what Debian is doing through the "apt://" URIs which, we believe, is just plain wrong as to the RFC standards). There are some problems with OneClickInstall, such as still being too complex for newbies, and Garrett made some interesting mockups (*) for a nicer UI as well as a somewhat easier workflow. But one way or another, you _cannot_ relieve end-users from having to care about digital signatures. And that's really the key problem regarding usability (or rather easy of use) here. (*) http://linuxart.com/log/archives/2010/06/21/one-click-part-2/ 3) Use repository metadata - -------------------------- As we didn't think that there would be enough people to maintain/define applications manually, we took the route of having a software based solution that automatically defines/detects applications from package repository metadata using some heuristics. As already mentioned in my previous posts, a few of those heuristics are: * look for a .desktop file in the files list of a package (which identifies a package as being an application, because it'll show up in the menu) * merge packages based on their %{SOURCERPM} RPM metadata tag to assemble them as applications (which catches subpackages) * the ability to define regular expressions to match additional packages with an application * use categories from the .desktop file to define tags on the application One problem became clear once it was implemented and up&running: we have way too many repositories to be able to process all that metadata properly, at least without having to scale out to several servers. The RPM-MD metadata is fetched every hour, and it regularly clogs down the server when it has to process all that data. We did optimize the SQL to the MySQL instance quite a lot, so that's not the problem. The issue might be that we also do compute a lot in the database to detect - - new applications (that have been added) - - updates to existing applications - - applications that have been removed and all that requires quite some juggling in the database. Having OBS (or rather the OBS publisher) ping the system would be a great plus, simply for the sake of a simpler implementation, live content, and scalability. 4) User feedback - ---------------- Screenshots, ratings, comments, all of that was obviously implemented as well. We also wanted (but didn't implement) to be able to link to blog posts, openSUSE forum threads, etc... The idea with rating was to give users a quick look at whether the application packages can be trusted. In our implementation, only blessed users were allowed to give ratings. And no, we obviously didn't use iChain as an authentication and/or authorization backend, we have our own user+role database ;) 5) Desktop client - ----------------- Once the Software Portal had been finalized (**), we would also have expanded the REST API in order to make it possible to implement a desktop client. The desktop client wouldn't need OneClickInstall and would also know about which packages are installed on your system, hence offering an even better user experience. But it never got that far. (**) which never happened due to lack of interest from others (we made a presentation about it at the openSUSE conference in 2009 (***), as well as blogged about it quite extensively back then, which is why I'm surprised so many people never heard of it -- yes, I do hate you people for that), and because Benjamin and I simply didn't have enough time on our hands to continue implementing it on our own (***) the PDF of the presentation is here: http://linux01.gwdg.de/~pbleser/swp.pdf More details on the wiki page we wrote back then: http://old-en.opensuse.org/Software_Portal Some screenshots: http://bw.uwcs.co.uk/swp/ cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iD8DBQFM1Urtr3NMWliFcXcRAhFFAKCE4RTwzNXBKbfcI4zuXvUlm1BPeACeKb0O x/byDkvQnZehEbfhNcdfiAQ= =0ZCE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org