Re: Welcome to ietf-nntp

["J.B. Nicholson-Owens" <[e-mail]>]

>For up-to-date information on the work done by this working group, 
>check this URL: http://www.academ.com/nntp/ietf.html.
>
>Archives of this list are available at this URL:
>	http://www.academ.com/nntp/ietf/index.html or

Neither of these URLs (quoted from the intro page when entering the mailing
list) seem to work.  I can reach www.academ.com, but I can't reach that HTML
code page.

Looking at the FTP archive it seems the list just started or no work has
been done (all I see are 4 test messages), so I'll throw out some ideas
based on work I am researching.

I am working on determining how well an RDBMS would serve as a back-end to a
Usenet server.  Right now, I envision using some program to turn NNTP
queries into SQL queries, feeding the SQL queries to the RDBMS and/or
retreiving the data from the RDBMS and finally formatting retreived data in
accordance with various RFCs.

I picked mSQL as the RDBMS I'd use (but any RDBMS that supports ANSI SQL
could probably be substituted) because it's free and it claims to support a
subset of ANSI SQL.  I laid out a few tables and went over each NNTP command
in RFC 977, drafting what SQL queries I will use to pull out the required
data.  Initially, I laid out the tables to maximize NNTP query speed.  It
made for some awkward table arrangements, but it seemed fastest to me.
Design has gone smoothly so far, but it is readily apparent that NNTP offers
very little searching and sorting capability.

So, somewhat out of curiosity and in anticipation for what the next NNTP API
would allow, instead of laying out the tables to make processing NNTP
commands quick, I laid them out in a way that would better aid doing various
kinds of searches (e.g., ``List all the messages by <user> written between
<date> and <date>'').  There are some things I'd still like to incorporate
better, (threading information, for instance, is done only by including the
entire References: header.  To better handle queries asking for articles in
a certain spot in a thread, it would be better if the server somehow used
relational pointers to know where in a thread each article belonged) but
it's interesting work nonetheless.

Any suggestions, pointers to relevant work or criticism is welcome.