Providing more information to users about a package
Colin Guthrie
gmane at colin.guthr.ie
Sat May 24 16:52:11 PDT 2008
James Westby wrote:
> We could draw up a standard way to make this information available,
> and then ask upstream projects to do so. It would obviously take
> a while before it is available for a large number of packages.
I think this sounds like a really good idea.
Some immediate thoughts that spring to mind:
1) A standard way of taking the homepage URI and adapting it to extract
the package info sounds like a sensible approach at first. This would be
similar to the (admittedly rather crappy) favicon.ico approach in web
browsers to display the little icon (I know there are more appropriate
ways to do this now in the HTML head). The argument that some projects
do not have control over their homepage is a fairly good one, but major
hosts like sourceforge would no doubt add support for this format if it
was to become popular. That said, it's probably quite complicated to
mangle the homepage URL so that this metadata can be grabbed, especially
when GET args make up part of the homepage URL...
2) Allowing individual projects to host their own screenshots and
perhaps a longer description etc. is a great idea dn distributes the
storage and bandwidth costs nicely. That said they are not going to be
impartial (having a bias is to be expected) about their app and if
reviews/popularity information is to be part of this, then it doesn't
really make sense to start off on a distributed system when a central
one would be able to provide a slightly more impartial slant and
ultimately better information to users.
With those two thoughts in mind, I wonder if a cross distro sponsorship
to expand an existing system is a better option? The most obvious one
that springs to bin is Ohloh.net It already carries a lot of information
about many open source projects and has a strong community both by
developers and users. It would make sense to add the ability to upload
screenshots etc (does it do this already? I can't remember off hand).
Not to associate a project with it's Ohloh "homepage" could be done in
two ways. 1) define a new field/tag/whatever in the various package
formats (we all have "Homepage" so we could add "Project Page" too. This
homepage would just be a metadata source XML file so the use of Ohloh
wouldn't be mandatory, but I think it should be encouraged due to the
impartiality reasons outlined above. I've found the Ohloh people quite
approachable in the past so it's almost certainly worth running past
them if other people think it's a good approach.
Just some idle thoughts before I hit the hay for the night.
Take care
Col
More information about the Distributions
mailing list