[wine] Soliciting suggestions for AppDB

[Chris Morgan]

Feel free to update the wiki page with the appdb ideas here:
http://wiki.winehq.org/AppdbInfo

Chris

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_
>
> 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')