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

[Duncan]

<address@hidden> <address@hidden>
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 68.230.66.193 (Mozilla/5.0 (compatible; Konqueror/3.3; Linux; 
x86_64) (KHTML, like Gecko))

Nicolas Girard <address@hidden> writes: 
 
> you may be interesting in trying a newsreader I discovered a while ago:  
> KLibido (http://klibido.sourceforge.net/) 
 
Interesting! 
 
> I intended to post a more detailed review to this mailing-list, but I've run  
> out of time, so at least let me say that: 
>  
> - not designed to allow posting 
 
Not a real big issue, really.  Just from what you say below, it looks to be a 
binary harvester type thing similar to BNR2/3.  While occasional single post 
replies would be convenient, it's really add-on functionality for this sort of 
harvester purposed app, as the parallel posting (post blasting) functionality 
master would be the CLI newspost, and its corresponding GUI front-ends 
GNewspost and KNewspost.  With that already available as a decent solution, the 
functionality even if eventually targeted, can wait until even a 2.0 version or 
later. 
 
> - Automatic joining of multi-part posts 
> - Automatic decoding of posts, using uudeview ; yenc also supported 
> - Multiple servers support, with priorities and fallback if an article  
>   fails on a server and is present on another server 
> - Multiple download threads per server support, with the ability to add or  
>   remove threads "on the fly" 
> - etc. (see the homepage) 
>  
> - I could quite easily compile and run it on a Mandrakelinux box 
 
Cool.  I'm very much a FLOSS supporter and the main reason I've not installed 
BNR2/3 is that it's not fully open source.  Thus, in addition to the good news 
about it actually compiling and running without huge issues, this is GOOD news 
indeed.  (The original significance of the sourceforge URL above didn't 
register, initially, so I was tremendously relieved to see you say compile, 
here.  Then I saw the sourceforge URL above and ...) 
>  
> - Please beware of optimizations when compiling ; Klibido crashed several  
> times when using optimizations on my box, and apperaed to be more stable  
> withour optimizations. 
 
Good to know.  I've actually had very little problem with optimizations here on 
my AMD64, even when I comment out the optimization filters in the Gentoo 
ebuilds (yes, I use Gentoo, on AMD64) so it used my optimizations.  Then again, 
I don't get quite as ridiculous about them as some do.  (I use -march=k8 -pipe 
-Os -fomit-frame-pointer -funit-at-a-time -frename-registers -fweb, fairly 
conservative, really, compared to the unsafe math options and others I've seen 
tried, to get that last little bit of performance.  That's using the latest 
gcc-3.4.3, glibc-2.3.4.20041102, and binutils-2.15.92.0.2-r1.)  Still, it's 
good to know it's caused others problems. 
 
Of course...  I *DO* have to worry about possible 64-bit unclean code. 
 
Hmm... just checked...  An "emerge -s libido" doesn't turn up an ebuild in the 
Gentoo portage tree for it yet.  I'll have to check bugzilla and see if one's 
listed there as in process, and consider trying my hand at making one, if not. 
 
> Oh, and while I'm there: Duncan, I know you had been considering using SQLite 
>  
> for Pan's backend before the development branch got frozen ; I've always  
> thought it was a very well-advised choice, as SQLite is amazing ; but  
> Alessandro, the main Klibido developer, chose to use Berkeley DB... perhaps  
> you'll be more successfull than I to try & convince him to consider giving  
> SQLite a serious try ? 
 
Interesting.  I'm not really a db expert myself, either.  What I've mentioned 
here has really been pretty much parroting what I've read on the devel list.  
Charles was the first to propose SQLite (that I saw, anyway), and those working 
with PAN's db-be had no strong objections, so just followed thru (as I read 
it). 
 
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 many distributions, due to 
other things that use it.  I expect it would be the same on the BSDs and OSX 
(BSD based) as well, or even MORE so, given the "Berkley" in common, which may 
(or may not, I said I'm not an expert) indicate origin. 
 
2)  SQLite while not as commonly installed, *IS* format-compatible with MySQL, 
should someone wish to do something more complex with the data gathered by an 
app considering using it.  That opens up ALL SORTS of interesting 
possibilities. 
 
3)  BerkDB's **BIGGEST** liability in context, AFAIK, is the fact that the 
format changes between versions, and isn't standardized except with itself 
(altho that's no small consideration either, given its wide usage).  SQLite 
format by contrast IS cross-version stable, and should remain so for 
compatibility reasons. 
 
I'm guessing he used BerkDB because it's so common and he was already familiar 
with it.  It's may also be easier to work with in some ways for a developer 
only worried about his own app, and not specifically targeting cross-app or db 
standards compatibility.  For the same lack of compatibility mandate reasons, 
it may be more direct and efficient, as it doesn't have to drag old 
compatibility baggage around (again, not that I really know, just guessing 
based on general knowledge). 
 
For the same reasons from the flip side, SQLite would have fit the grander 
goals of PAN, to be THE "Pimp-Ass Newsreader" to beat ALL newsreaders.  
Obviously, PAN has a LONG way to go to get there, and may or may not ever make 
it, but that format interoperability would DEFINITELY be seen as a bonus, as 
one of the defining characteristics of such a newsreader would be its ability 
to plug into a larger framework, for instance, such that a music or movie 
management application may be able to be built to share the same data backend 
and catalog and index both files downloaded using PAN and loaded into the 
database using other means, PLUS having the ability to include not ONLY the 
standard file data, but ALSO that found in the newsgroup posts themselves 
(possibly automatically filling in ID3 tags with info from the subject of the 
newsposts, as well as displaying it in the media management application itself, 
for instance). 
 
Anyway...  aside from me not being the one to make the case, as I really don't 
know what I'm talking about, if the info I've gathered and reproduced 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.  PAN's solution may /ultimately/ be better, 
five years or a decade from now, but OTOH it may never get there.  KLibido 
apparently has a working solution NOW, and what works now gets used now.  <g>  
I'd hate to send him on a goose chase and break a currently working solution, 
for something that may or may not work better in the end, particularly when 
there's another app intending to do the other solution that just hasn't gotten 
there yet.  <g> 
 
Duncan 
(again, using the gmane web interface as news.gmane.org is currently down)