[Top][All Lists]

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

Re: [Pan-devel] Re: Move to database back-end

From: Tom Enterline
Subject: Re: [Pan-devel] Re: Move to database back-end
Date: Thu, 11 Mar 2004 23:46:47 -0500

On Wed, 2004-03-10 at 07:23, Duncan wrote:

First, I apologize for the duplicate posts, I thought the forwarding was
handled automatically, but I didn't see anything for a day after I
posted. So I thought that maybe my post was rejected since it wasn't
sent from the ID I used to sign up for the list.

Also, Duncan, I just want to say that I'm amazed and appreciative of the
amount of work you put in at pan-users. 

> Charles or Chris will be able to answer in more detail from the PAN
> development angle.  I'm just a list groupie, more than anything, who
> understands just enough about development to get what's being discussed,
> but I can at least fill you in on the list history on the topic..

> 3. Tool of choice?  Charles has mentioned SQLite, in the context of
> integrating it as a library much as PAN does with gnet for the network
> side.  I know little about it, but from comments he's made, SQLite is a
> fairly light library (again, similar to gnet) that would allow PAN to
> borrow its more robust data implementation, while not requiring that users
> install an entire database application such as MySQL, just to support PAN.
> An additional advantage, however, is that SQLite is MySQL compatible, so
> users that wanted to expand on PAN's abilities with full database
> functionality could do so using MySQL.  That would lend PAN some serious
> flexibility in terms of potential third party extensions and tie-in apps.

I did check into SQLite, but didn't know about the MySQL compatibility.

> Obviously, tracking all this is exactly what a database is good at.  In
> fact, I'm not sure how BNR2 handles it, whether it depends on Delphi/Kylex
> tools and libraries or whether it manages its own (I've never used Delphi
> myself, so..), but whatever it does, it definitely isn't as robust as it
> COULD be, because from the posts I've read of users, many/most of them are
> quite familiar with the procedure of deleting the database files and
> letting BNR2 rebuild them due to corruption.  This could be PAN's
> opportunity to out-compete this competitor, once it starts playing in the
> same competitive space.

Given that the database could be on an non-journaled filesystem (ext2fs,
fat32), I don't think it would be practical to guarantee to never
corrupt the database. However, perhaps the rebuild process could be

> Quite a vision, I think, tho of course that of others might be different
> (but this vision would allow that..).  PAN has quite a ways to go, but the
> solid foundation as a newsreader is already there, and with the proper
> implementation of the database backend, provided it's done with this sort
> of flexibility in mind, we could be easily be on our way..

We definitely need a vision. In the near term, it wouldn't surprise me
if the version of PAN that implements the new backend had few
user-visible changes - the new backend will involve substantial changes
on it's own. Of course, once that's in place, other changes become much


reply via email to

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