[wine] Soliciting suggestions for AppDB

[David Lee Lambert]

On Wednesday 08 June 2005 08:32 pm, Mitchell Mebane wrote:

> I'm putting together a Summer of Code proposal for working on the AppDB.
> I've been talking with Chris Morgan, and he has a few suggestions, but I
> was looking for more. Does anybody have any features they'd like added
> to the AppDB, quirks they'd like worked out, or things of that nature?

I have some ideas about the AppDB,  but I've been working on some of them 
myself,  and others really need the approval of the WinHQ webmaster more than 
anything.  Still,  I'd like to hear what other people think of them:

1.  The AppDB, Bugzilla and the Wiki ought to send last-modified information 
for most of their pages.  This would speed things up,  in some cases, for 
dialup users,  but the real advantage would be as protection against a 
slashdotting or onslaught of AOL users.  Many of the pages also send other 
headers that prevent caching of positive lookups.

Today I sent a patch to the AppDB maintainer to do this for images,  which are 
probably the biggest performance hit (they cause the AppDB main page to take 
about 30 seconds to load over a dialup connection).  However,  almost any 
page in each of these databases could in theory be cached.  Bugzilla bug 
display pages already display a "Last modified" datum in the text of the 
page,  and so do Wiki pages (bug 2889 mentions this).

Several of the AppDB tables already have TIMESTAMP columns,  so I was planning 
to write some code to just gather them all together and send the latest one 
as the last-modified date.  The only problem is that if a page contains an 
item which is then deleted,  its timestamp will go backwards.

2.  The "robots.txt" on bugs.winehq.org is overly restrictive,  and the 
'robots.txt' on appdb.winehq.org and wiki.winehq.org are HTML pages.  (Yes,  
I know that they have a big red "404" in the middle when viewed by a human,  
but they come back with "200 OK" responses to a spider).  There might be 
fewer duplicated requests for help in different places if search engines 
could actually get at the text of bug reports and app comments.

3.  It would be nice if the application display page could do a query against 
the Bugzilla database directly,  and diplay it, something like

(no reported bugs)  _add one_

or

[12 open bugs, 6 closed]  

with the numbers being links to the Bugzilla query page for full details.

It would also be helpful to be able to associate a bug with more than one 
application.

4.  The wiki should recognize the phrases "app <number>" and "bug <number>" 
and make them links to the corresponding AppDB and Bugzilla entries.

5.  Perhaps the information about Linux alternatives for each app could be 
kept as a separate table,  instead of as haphazard notes in app descriptions.

6.  There are a couple more flags that would be nice:

license ENUM('OpenSource','Freeware','Commercial'),
availability ENUM('Available','Discontinued'),
linuxVersionAvailable ENUM('Yes','No') 

-- 
DLL

GPG key at http://www.cse.msu.edu/~lamber45/newmail.htm?GPGkey