[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnupedia] Architecture Questions

From: Mike Warren
Subject: Re: [Bug-gnupedia] Architecture Questions
Date: 21 Jan 2001 03:16:05 -0700
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko)

"Hook" <address@hidden> writes:

> For anything other than small collections of files, it's almost always
> faster to find information using a properly constructed database.  Human
> readable files holding the content are indeed A Good Thing (tm), however,
> the meta information (author, title, subject etc) are probably better stored
> in a database for ease of access, ease of updating, simple multi-user
> access, searching etc.

I agree, for most things. However, classifications (and hence searches) should
be in a separate layer. These layers might benefit from a database, but the
raw content will always be accessed by its unique-ID.

When a classifier checks over the articles, all it needs is the index
of all articles' unique IDs. It can then determine if it knows about
that article or not.  If not, it should retrieve it and add the
appropriate information to its database.

For example, the back-end might have two articles:


It would also have an index file, with exactly those two file-names
listed in it. Then, the classifier retrieves the index at some point,
when its doing its update, and notices that it doesn't know anything
about an article with unique-ID 987654, so it retrieves it from the
back-end. Let's say this particular classifier is a ``kid's only''
one; it lets the moderators of the classifier look over the content
and they decide that this is ``adult'' stuff, so it places the unique
ID in its ``don't display'' list.

GPG: 0x579911BD :: 87F2 4D98 BDB0 0E90 EE2A  0CF9 1087 0884 5799 11BD

reply via email to

[Prev in Thread] Current Thread [Next in Thread]