On 8/16/02 9:31 PM, "Tom Neff" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject.
