Lionel Ulmer wrote:
> I have one problem with keywords is that I do not trust anyone to enter
> 'correct' informations :-) IMHO, the more directed the 'user' is, the better
> (or else, all the burden is reported on the database maintainer who will
> need to rewrite 90 % of the submissions).
>
> I am not against giving the user the possibility to add 'free form'
> keywords, but all informations that we need to generate pages should come
> from 'trusted' sources.
I see your point. However, I think there is a balance
to strike. If you have a 'genre' field, people
will type garbage into the field (or a wrong entry)
just to get past it.
Perhaps we could have two ways of entering keywords,
a drop down list of trusted keywords, and an optional
free form entry of keywords. If it's easy to skip the
optional section, most people would, and then we wouldn't
get too much garbage in.
>
> > Also, I think it's vital that in addition to a trusted application
> > database maintainer role, that we also have many people
> > who can be trusted maintainers for a specific application.
> > To that end, the apps db should have a web page
> > element ala source forge.
>
> What do you mean by 'web page element' ?
Sorry; I mean that each application would have it's
own Wine web page. Thus, there would be a ./juno.html,
a ./monkeyisland3.html, and so on. The idea is that,
just as SourceForge created a home for many projects
floating around out there, I think the apps database
could create a home for all of the Wine info floating
around out there.
>
> Here I start to disagree :-)
>
> First, I do not think the application description should be in HTML. But as
> this is a detail, and does not impact in anyway the database organization, I
> will let it pass for now :-)
>
> Secondly, another way to fix the Activision / iD 'problem', we could add a
> 'ReleasedBy' relation instead of putting the 'Vendor ID' in the Application
> Family table (ie Quake 3 would have two 'vendors', 'iD' and 'Activision').
>
> For the multiple name problem, adding a 'Aka' relation and an
> 'AlternateName' table would also solve the problem (instead of putting it in
> the 'keyword' area). Same thing for the 'genre' (creating an 'IsOfGenre'
> table and a list of GenreIDs).
Hmm. I disagree, but only mildly. I suspect
that this is the sort of thing that will evolve as needed,
and your proposed structure does solve the problem nicely.
My key concern is that because we can see all of the
complex exceptions (e.g. Quake III), we're going to
have an interface that handles all of the exceptions,
instead of being brutally simple for the majority
of non exceptions.
[snip]
> What is your Project ID here ? I did not see any other Project table
> anywhere :-) I think you meant 'in the API database'. And I did not exactly
> understand what a Project is in the API database :-)
Sorry, I do mean the API database - that was a typo.
(Documenting the API database better is on
our list of things to do...<g>)
But to try to explain quickly, a project is
just that to us - a customer project. So, say we have
company XYZ that wants to port product A. We run
a static analysis (just a dump of exports), and
filter it through some neato code of Charle's,
and now we have a list of unique external function calls
made by product A. At one point, Charles had it
so I could upload a zip file containing all of
an apps exes or dlls (or the result of a dumpbin),
and he'd autogenerate this function list. I don't
know if that still works.
So, a project is associated with a given
Windows application, and consists of the list of
all Windows functions used by that application.
[snip]
> Well, I do not find that Wine vintage should be optional... It's as
> important IMO as the date entered. When one sees how many questions are
> asked for ages old Wine version, I would prefer the user having to check his
> Wine version before entering a report.
I'm easily persuaded on this one. My only concern was
for people who were getting Wine that came with a distro,
and so wasn't readily identified, but I think you're right.
>
> And there would still be the problem of scoring. Should be we have a single
> note or separate the scoring (on UI correctness, speed, usability, ...) ?
>
I don't know the answer.
However, perhaps we could add a weight as part of
the score. That is, we could ask how often the user uses the app.
Everyday, occassionally, or 'I just brought it up to
see how Wine works and then rebooted to Windows, but it
rocks, man!'.
Jeremy
