Re: [Pan-devel] The Blue Sky Becomes Clear - part 01: Basic Thoughts - revision 00

[Duncan]

On Sat 05 Apr 2003 22:01, Haran Shivanan posted as excerpted below:
> Wouldn't a database be overkill for people that have less than 100K+
> posts?
> On that note, what is the typical usage of a newsreader?
> Do typical users keep a lot of posts?
> I was under the impression that Google Groups had made the need for this
> unnecessary but I could be wrong.
> FWIW, I personally store less than 500 posts in a newsgroup. Even that is
> on the high side.

Google Groups only archives public groups..  Many ISPs and NSPs have 
non-publicly distributed private groups, and some users find it useful to 
have archives of said groups going back quite some time.  Of course, a few 
users just want the convenience of having the archive entirely local, and 
find it's actually quite possible now days, with disk sizes what they are, 
provided they stick to a limited number of text groups of less than 
"super-crazy" activity levels, of course, providing they use a reader that 
will accomodate that desire..

As for the db, most readers including PAN already use some form of db to 
manage the various groups, and tracking message status, etc.  From previous 
discussions, major features such as virtual server and virtual newsgroup 
management, where the same group can be tracked in the background on several 
servers (virtual server) and/or several physical groups can be combined into 
a single logical group (virtual newsgroups), all transparent to the user, 
cannot be so easily implemented until PAN gets a more robust db system in 
place.  This has tentatively been penciled in either b4 1.0, or after 1.0, 
for what would then become 2.0.  As so far discussed, it would probably be 
implemented with the SQLLite libraries, just as PAN now implements its 
internet connections using the gnet library.  Again, just as the gnet library 
brought additional features for comparitively little additional coding, so 
would SQLLite.  One of the most interesting features, for those that might 
wish to use it, would be the MySQL (IIRC) compatibility.  You are correct in 
that the full features of MySQL are overkill for PAN, but given the stated 
goal of becoming in the full featured sense a "Pimp-Ass Newsreader" second to 
none, the SQLLite db transition will enable some pretty heavy duty features, 
and the MySQL compatibility just happens to be a big bonus, for those wishing 
to then use it for further management and tracking of news, and potentially 
fully integrating ALL their binary media management and tracking needs, of 
which PAN could then be potentially only one small piece.

Using SQLLite, a (from all accounts) fairly trimmed down library itself, to do 
much of what PAN does on its own now, won't be all that MUCH overkill, even 
if you continue to use PAN in a more traditional news client roll.  However, 
it WILL give PAN the ability to scale and include some of these fancy 
features, that are simply impractical, now, for those wishing to use them.  
Consider that much of the code functionality now implemented in PAN itself 
can then be handed off to the SQLLite library, and PAN the binary itself will 
likely be smaller, initially after the switch to using SQLLite.  Of course, 
adding all those features will bring it back up in size, but by offloading 
the db management and other common functions to libraries, as it does now 
with gnet for internet access, will mean the PAN code base itself remains 
reasonably managable, even as it adds serious big-time features that would 
otherwise bloat it beyond all control, recognition, and managability.

-- 
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin