An idea for the appdb

[Ben Klein]

2009/2/12 Gert van den Berg <wine-devel at mohag.net>:
> On Wed, Feb 11, 2009 at 2:24 PM, Luke Benstead <kazade at gmail.com> wrote:
>> 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).
>>
> Wine transmitting every application I run to someone else would be
> rather worrying...
>
> It should rather be opt-in. Such as "Wine has detected that it is the
> first time you run this application, do you want to check AppDb for
> more information (Yes/No/Ask again/Never ask for any application)"

This would get insanely annoying if you wanted ONE app to grab data
from AppDB but not every other one.

> It must be easy to disable globally as well...  It might have some
> other uses as well such as "A newer version of the application
> works better", etc.

Reliability of AppDB data is the issue here.

> I might be handy to allow automatic submission of test data to AppDb
> (which IMHO might be more useful than just retrieving...)

Automagically ask the user how well their app runs? No thanks.

>, which should automatically include the Wine executables'
> checksums + version, distro info (if accessible from lsb-release,
> parts of the uname output & kernel checksum

Kernel checksum? No thanks. Especially as a lot of people compile the
kernel themselves (Gentoo being the prime example).

> , which might be used to detect the distro), kernel version,
> cpu architecture, X server name and version, graphics driver name
> and version, DLL overrides, etc.

That's a lot of info you're collecting. Even with an opt-in service,
it could be easily mistaken for spyware. Tread carefully.

> This might help modified wine versions and the level of tweaks
> to be detected by AppDb automatically.

Um, no. The big problem is patches, not just DLL overrides.

> (There should be a very specific opt-in process for
> this data's submission though, such as letting the user manually
> upload a file with this data and fully disclosing the file's contents)

OK, so instead of an automagic system that collects all the data, a
manual system that collects false data? Doesn't sound any better than
AppDB as is.

> This kind of data can be handy for bug reports as well.

This kind of data is typically retrieved on-demand in bug reports. The
WORKSFORME bug status is evidence of this.

2009/2/12 Tim Schwartz <tim at sanityinternet.com>:
> What about packaging the latest appdb information with each release?

Because it's BIG. It would also be at least one release behind in test
data, making it completely useless.

2009/2/12  <alex at centroidcafe.com>:
> Automatic submission of test data could be a very handy tool. Scenario:
> User A tries to run an application, it crashes due to bugs in Wine. User A
> elects to submit data. Sometime in the future, User B tries to run the same
> application under a similar configuration. It crashes also, but User B
> being a sly user figures out what DLL overrides, patches, etc. allow this
> app to progress past the original crash point. Wine detects this and
> collects the information. Now when User C tries to run this app, Wine
> displays a message like: "This application has been known to fail under the
> current configuration. However, workarounds have been discovered that may
> yield greater success. <link to AppDB>"

Microsoft, KDE and a few other systems have this type of automatic
crash reporting. It doesn't work. You are suggesting a new system
here, which is storing automated crash report data in a database which
will be looked up every time an app runs. This would be a massive load
on the server, even just on requests for applications that don't have
entries.

Would you seriously want to maintain a database of every Windows
application in existence? Seriously? Because that's effectively what
you're suggesting. It's not even just Windows apps either, but DOS
apps too. Wine will attempt to load DOS apps, and almost always crash.
An automated crash report system wouldn't know the difference between
a genuine win32/win64 app and a DOS app without a lot of extra work.

I don't have to respond to Austin's comments. It's all been said
before. Simple answer is: would not work.