-----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/
/\\