I expand here on the ideas developped by Jeremy in his mail to the
wine-devel mailing list [1] to create a new improved Wine application
database (I had a bit of time on my hands during these vacations
without a Linux PC but with a text editor :-) ).
I) Goals
=====
The ultimate goals of this database are :
1) list all working and non working applications. With the 'scoring'
of applications, we can have an idea of :
- the progress of Wine
- the most wanted applications
2) for working applications, this database should be the reference on
HOW to get them working (ie last working version of Wine, Wine
configuration regarding native / builtin DLLs, ...).
3) when Wine will be out of alpha state, this database could be the
basis for a distributed regression testing system (if we get enough
people involved in the Wine project by taking 'ownership' of an
application and do regular bug reports / regression testings).
Some other ideas could be :
1) if we add some 'relay statistics' in Wine code (of course, there
will be problems with COM objects where relaying does not work for
now) and incorporate these statistics in the database, we could
have a list of the most frequently used Windows calls.
(feel free to add new ideas for improvements :-) )
II) Database content
================
Now let's see how we could organize the content of the database. These
questions may seem details, but if one want to create a database
scheme behind for a database engine, these questions need to be solved
:-)
A) How to 'classify' applications ?
--------------------------------
In his mail, Jeremy proposed the following classification :
Microsoft
Word
95
97
2000
Excel
...
But what about application like Photoshop where you have version 5.0,
5.0 LE (the light edition that is given as a package with your
scanner), ...
Should id be :
Adobe
Photoshop
4.0
5.0
5.0 LE
or
Adobe
Photoshop
4.0
5.0
retail
LE
And if you add games, the situation is different again. Should we have :
LucasArts
Monkey Island
1
2
3
4
Or :
LucasArts
Monkey Island 1
Monkey Island 2
After, the situation is getting even more complicated with games
(maybe also for other applications, but I never use any of them) :
= Should 'demoes' be part of the database (I think YES because it's
often the only way for a Wine developper to test and debug an
application) ? If yes, what should the organisation be ? Have a
specific 'page' for the demo or have the demo information be part
of the main game page ?
= games have often many 'patch' versions that can have different
behaviour in Wine (for example, the first versions of HalfLife had
some OpenGL problems that the latter do not have anymore). I do not
even speak about 'mods' like CounterStrike :-)
= often, editors and realisation are not the same (should we have
'iD software / Quake III' or 'Activision / Quake III' ?)
= and, finally, games can have more than one name ('Monkey Island IV'
or 'Escape from Monkey Island').
So if we do not want the application database to get messy pretty
quickly, all these questions should be answered before we start
working on it :-)
B) Should we add 'genre classifications ?
--------------------------------------
Should we add some 'genre' to the applications (from the most general
like 'Game', 'Application', ...) to more detailed ('Word processor',
'Web browser', ...) ?
I think that it will be useful (for example, I would only be
interested in Games running in Wine, so I could 'filter' on one
specific genre), but again, it's a can of worms :-/
C) What information should we have about an application ?
------------------------------------------------------
Informations that can be useful about an application (for debugging
purposes for example) :
= what 'kind' of application : Dos, Win31, Win32
= list of 'imported' DLLs
(feel free here also to suggest more things)
This kind of information should be autogenerated by Wine if we want it
to be fiable (for example, by a speficic new debug channel : when an
user wants to create a new application in the database, he just would
have to start 'wine --debugmsg +database_info myapp.exe' and paste the
resulting info in some web form to create all the relevant
informations)
D) And about an user ?
-------------------
To have some control on the database, only browsing should be done
without being 'registered', all the rest (application addition,
scoring, ...) should require registration to have a minimum of control
on the database (and also to prevent some completely bogus entries as
you need at least to spend 2 - 3 minutes to get your registration).
A part from the 'standard' things (name, nickbame, email, home page,
...), we could add 'configurations' for this user : all the 'external'
packages on which Wine depends (for example X / glibc release, system
version (Linux 2.2, 2.4, FreeBSD, ...), Windows present or not, if
yes, Windows version, ...) and the some relevant informations from the
.winerc.
A complete list of what would be needed for good debugging should be
done :-)
One user could have more than one configuration (for example, if he
has more than one Wine configuration). This configuration, to be
fiable, should also be created by Wine (or any other tool distributed
with Wine if we do not want to clutter Wine with 'useless' debug
code).
We could also add some 'Wine level' (from 'Wine newbie' to 'Wine guru'
:-) ) that could help to tune the results (for example, getting an
application score from only people that are 'newbies').
E) And about a Wine release ?
--------------------------
Of course, each time someone says 'this application works on Wine', we
need to know the version on which it was tested with plus some other
informations related to the Wine build (ie, from package, source ?,
was XXX compiled in ?, ...).
For the Wine version, I see different solutions :
1) add at each release two 'ids' in the database : the wine release
(for example wine_20001222) plus a 'CVS' id (wine_20001222_CVS
that would describe all CVS versions of Wine between 20001222 and
the next release).
2) add more labels in the CVS tree (for example after each bunch of
commits, create a 20001222.1, .2, .3, ... release) and create
these also as ids in the database. This would enable us to have a
better control on the CVS version.
3) put in the Wine distribution a tool that does the 'cvs update' for
you (as it is done in Mozilla). This tool would 'remember' for you
the last date of the update. Thus, when using a '_CVS' label from
1), the user could add the precise date at which the update was
done.
F) How about scoring ?
-------------------
With all the information gathered before, one 'testing' would be the
grouping of : an 'application', an 'user', a 'system' and a 'Wine
release'. After, what should we add as additionnal information ?
Should we use a single score (like in the current application
database) or separate the scoring (for example have a score for
different parameters like 'Graphical Correctness', 'Usability',
'Performance', ...).
Another idea would be to separate the scoring of the installation
procedure from the usage of the application (ie one application could
have a '0' in Install if you need to install it using Windows, but a
'5' if it runs perfectly once installed).
Do we want to have a 'comment' box for each 'test' where the user can
comment his or her results ?
Should a 'bad' score be linked to Bugzilla ? I.e. when an user enters
a low score, ask him if he would like to file a bug. Other
possibilities would be to display on each application page a list of
all open Wine bugs on this application. The database would also serve
as entry point for Bugzilla : each application page would have a 'File
a bug' link.
G) What additionnal information should one application have ?
----------------------------------------------------------
There need to be two important informations :
- how to install the application using Wine
- how to run the application using Wine
One way to organize that would be to have an 'official' page for the
application maintained on-line (using a system similar to a Wiki [2])
by the application creator (with a more advanced system, by all user
allowed by the creator to make changes). This 'official' page would
have all the summaries of the different scorings.
After, two other possibilities :
- having a page display all the scorings + all the comments to have
more 'details' on who is running this application
- add either a discussion board (I HATE web based discussion boards
so you will need to have very strong arguments :-) ) or a 'public'
Wiki page which could be changed by anyone (even un-logged ?).
Of course, all this is a bit the 'ideal' app database as I see it and
would take much work to implement... But well, this mail is here to
start a discussion on this VERY important topic :-)
I would be ready to start to work on this, but we would first need to
see exactly what to put in the base.
Lionel
References :
[1] http://www.winehq.com/hypermail/wine-devel/2000/10/0150.html
[2] do a Google search on Wiki, you will find MANY examples of them
:-)
