An idea for the appdb

[Ben Klein]

2009/2/11 Luke Benstead <kazade at gmail.com>:
> 2009/2/11 Ben Klein <shacklein at gmail.com>:
>> 2009/2/11 Luke Benstead <kazade at gmail.com>:
>>> My idea is that the appdb should allow for people to associate a list
>>> of checksums with an application version. For example, WoW might have
>>> the checksum for the setup program and the game's executable,
>>> associated with the appdb entry. The other extension to the appdb
>>> would be to allow a way to programmatically retrieve information on an
>>> application's rating etc. by going to a certain address (e.g.
>>> http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...)
>>> which would return the info in XML or some other format.
>>
>> You've clearly put quite some thought into this, which is highly
>> commendable. However, I would personally be against such a move, as it
>> would put a lot of extra load on AppDB (in terms of network
>> bandwidth). I'm also not too keen about something that retrieves data
>> from the net every time you run an app. It's too easy for people to
>> mistake it for spyware.
>
> Hmm.. I see your point. However would it really use that much
> bandwidth? I mean, any sane implementation of the functionality I
> described would only display the dialog the first time that
> application was used. Retrieving a tiny xml file is surely less
> bandwidth than browsing the appdb for the application (granted it will
> happen more often than people browsing the site but I still don't
> think it's masses of bandwidth). I can also see what you mean about
> spyware, but other apps retrieve stuff from the web if there is a
> connection (CDDB, and album covers are two examples).

A request to AppDB would be at least once per user, application
version and Wine version combination. Given the number of people using
Wine, this would almost certainly be a massive load increase on AppDB,
it would repeat roughly every 2 weeks (when new releases come out),
and possibly even bring AppDB down as a worst-case scenario.