Re: [Pan-users] Re: has development of pan stopped since januari 2004?

[Charles Kerr]

Duncan wrote:

> * Fully automated multi-server support, with priorities and fallback
>   (Note that this is more advanced than PAN, but of course PAN does
>   posting and text while klibido doesn't.)

Nice.  Is the GUI for this worth stealing? :)

> * Berkley DB backend (where PAN uses the GTK+ widget limited data support
>   and handles its own backend, currently, and looks to be switching to
>   SQLite in the future).

Yes and yes.

> > I'm not really a db expert myself, either.  I don't know anything about
> > the comparative performance aspects of the two, but from what I've read,
> > there are a number of other aspects to consider.
> >
> > 1)  BerkDB is *VERY* commonly already installed on *ix.
> >
> > 2)  SQLite is format-compatible with MySQL, [which] opens up ALL SORTS
> > of interesting possibilities.
> >
> > 3)  BerkDB's **BIGGEST** liability [is] inter-version format changes.

It doesn't matter how common bdb's installation is when there are 
inter-version changes.  Back in the bad old days of Pan using bdb, I got 
daily mail from people who'd upgraded Pan to find the new RPM linked 
against a different bdb, or upgraded their OS to find a different bdb, 
so that Pan didn't run anymore.  I got these *daily* until I ripped bdb 
out of Pan for good.

Also, it's worth noting that SQLite is small enough in LOC to be bundled 
with Pan or klibido, making (1) and (3) moot.

> > Aside from me not being the one to make the case as I really don't know
> > what I'm talking about, if the above is correct, I'm not sure that
> > switching /would/ be the right decision. Yes, it would /ultimately/ be
> > better, /if/ it ever gets there.  However, keep in mind that he's got
> > the working prioritized multi-server implementation that PAN's only
> > dreaming about, at this point. [That's more than PAN has, with it's
> > supposedly "better" choice that hasn't yet been implemented.]

Multiserver will not be all that painful to add to Pan.  The queue code 
will already support it now that the socket pool is in place.  The two 
remaining pieces are for (1) Task <-> Server to be one to many rather 
than one to one, and (2) for the backend to give the task manager 
MessageIds from more than one server.  (1) is easy; (2) is a little 
harder without the database in place.

Actually, if the news servers support fetching by Message-ID, we could 
skip (2) altogether for the short term.


> I've long figured that if/when I go get serious with open source
> programming, a news application would likely be my first project, since
> I've quite an interest there so it fits that "personal itch" requirement. 
> PAN always looked to be the closest fit to my interests in that field,
> altho in general I'm more naturally at home with KDE, and had often
> thought to myself "if only PAN were KDE based.  Until now, lacking the
> coding ability, I contributed to PAN where I could -- by being a constant
> presence on the lists/groups and answering questions as I could.

Which I've very much appreciated. :)

> Anyway, it would now appear that klibido /might/ just be the opportunity
> I've been looking for, to scratch that news itch on KDE.  It's possible
> (I'm not going to say probable just yet, after all, I haven't even
> installed the program yet, let alone contacted the lead developer <g>)
> klibido will be my first serious code contributory project.  If time
> brings that about, I may just have the opportunity to make the case for
> SQLite -- or not, if BerkDB was chosen for a good reason.  Of course,
> that's where I was headed with all the above <g>, but there's a bit more
> to it as well.

If you do contribute to klibido, yes you should argue for SQLite, for 
the reasons listed above and also so that Pan / klibido compataiblity 
might happen sometime down the road...

> If that happens, I'll probably lower my profile in the PAN groups/lists.
> (I get these mailing lists as groups on gmane.org -- I really DO prefer
> news to mail, and news is /really/ a personal itch that I hope to
> scratch.)  Whether I'll keep PAN for my text group work or switch to
> KNode, now that I won't have to worry about binary groups, since klibido
> will be handling them (still presuming it works as advertised and that I
> can even compile and install it on AMD64), I don't know, since I haven't
> used KNode in a /long/ while.  On the one hand, I've very familiar with
> PAN and would like to continue using it, if only for text groups.  On the
> other, switching to KNode would mean I could dump a lot of GTK stuff,
> since PAN is about all I have using it.  (Tho I think XMMS does, but maybe
> I'd switch to Noatun or KJuk or something, if I didn't need GTK for PAN.)

Well, this is intractable, so if you decide you've just got to get rid 
of gtk, then you're not likely to be using Pan.  C'est la vie. :)

> Of course, also of significance is that klibido is very new, as I
> mentioned, first changelog entry being 2004.08.03.  It's entirely possible
> it would have never come to pass, if PAN development hadn't stalled.  The
> author may have stayed with PAN and contributed to its further development
> instead, if it had seemed it was going anywhere this past summer. 
> However, if he's more comfortable in KDE and with C++ anyway, and with PAN
> apparently stalled, he probably decided it was easier to start his own
> project than work on and possibly take over lead development of PAN, which
> isn't in his evidently preferred environment anyway.

The more the merrier, IMO.

Anyway, let me know what you find after running klibido for awhile. 
Pan's multiserver will come when it comes, and a Qt frontend isn't 
planned at all, but it would be nice to steal any ideas worth stealing.

cheers,
Charles