> I strongly agree with what both of you have suggested; I particularly
> think Francois is correct to suggest that we resolve some of the
> hierarchy/name space issues with keywords.
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.
> 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' ?
> Agree. But I vote we simplify drastically to use just keywords, and
> normalize, something like this:
>
> Vendor DB:
> Vendor ID
> Vendor Name
> Vendor URL
I agree with that :-)
> Application Family DB:
> App ID
> App Name
> Vendor ID
> Keywords
> App description (HTML)
> App web page (URL, e.g. www.winehq.com/juno)
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).
And by the application web page, I suppose you speak about the 'official'
web page and not a Wine specific page on this application ? (I was a bit
confused by your example).
> App Version DB
> App ID
> App Version ID
> Version Name
> Keywords
> App description (HTML)
> Version Web page (URL)
> Project ID in the application database
> (lets user enter relay trace/static analysis trace to
> generate list of APIs used by this app)
> (Score data; built nightly)
> (Bugzilla list; built nightly)
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 :-)
And the HTML for 'installation' instructions and 'usage' instructions should
be in this table. Or if we do not want do separate both, a single HTML under
the responsability of the app maintainer (or was that your 'App description'
field ?).
The problem here is how you manage application without a 'version' (like
most games) ? Should an automatic 'App Version' without any name be created
for each new application Family ?
> User Experience DB
> App version ID
> User comments (HTML)
> Test platform (optional)
> Wine vintage (optional)
> Date entered (so it can expire)
> Username (same as bugzilla/API db)
> ~/.wine/config file used (optional)
> Score
> Bugzilla bug ids
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.
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, ...) ?
> Keywords DB (autogenerated)
--
Lionel Ulmer - [EMAIL PROTECTED]
My Advogato Wine diary : http://www.advogato.org/person/bbrox/
