On 8/16/02 9:31 PM, "Tom Neff" <tneff@grassyhill.net> wrote:
> The meta-lesson, if you will, is that you should store your list archives
> in the most presentation-independent format possible, so as to preserve
> your options when you change your mind every five years, or when archive
> browsing technology leaps. Don't cook messages permanently into HTML pages.
That's exactly what germinated this idea. USENET fails to scale because it
sends every byte every where in case anyone anywhere might want it. Programs
like pipermail and Mhonarc have the same general problem, generating all of
the pages and all of the links in case someone might want any page from any
link. While you can regenerate things if you want to change them (say, new
headers and footers), it's a royal pain in the ear.
So what I decided to explore was to simply (hah!) dump everything into
MySQL, use MySQL's fulltext search system as the basis of a search engine,
and then start building interfaces to the data -- and just create an api and
environment to allow people to build interfaces to the data. The data lives
in the database. It's never changed. It's simply made ready ofr display.
Want an iMap interface? Fine. Web sorted by list, date and author? Sure.
Threaded? No problemo. Based on the octal represenation of the 12th byte of
the 4th paragraph? Sure, why not?
What we want out of the data changes over time. So quite putting the data
into display format, stuff it somewhere and manipulate it as needed. Most
archives are pretty low access things anyway, so building index pages on the
fly just doesn't seem to be a huge issue to me. (again, hah)
--
Chuq Von Rospach, Architech
chuqui@plaidworks.com -- http://www.chuqui.com/
Someday, we'll look back on this, laugh
nervously and change the subject.
Follow-Ups:
References:
|
|
