[wine] Soliciting suggestions for AppDB
cmorgan at alum.wpi.edu
Tue Jun 14 22:39:26 CDT 2005
Feel free to update the wiki page with the appdb ideas here:
On Tuesday 14 June 2005 12:48 pm, David Lee Lambert wrote:
> 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_
> [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
> 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
> 6. There are a couple more flags that would be nice:
> license ENUM('OpenSource','Freeware','Commercial'),
> availability ENUM('Available','Discontinued'),
> linuxVersionAvailable ENUM('Yes','No')
More information about the wine-devel