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

[Tom Enterline]

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.
Interesting.

> 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
simplified.

> 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
easier. 

Tom