pan-users
[Top][All Lists]
Advanced

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

[Pan-users] Re: Newspost


From: Duncan
Subject: [Pan-users] Re: Newspost
Date: Mon, 25 Jul 2005 01:53:52 -0700
User-agent: Pan/0.14.2.91 (As She Crawled Across the Table)

Graham posted <address@hidden>, excerpted below,  on Sat,
23 Jul 2005 19:25:51 +0100:

> Is there any news on support for newspost internally in Pan to make binary
> postings?

I don't expect that for some time, if ever, tho PAN may borrow some code
from it.  There's already knewspost and gnewspost as graphical front-ends,
if desired.  When PAN gets binary posting, it /may/ be only "trivial"
level, that is, single part, without the batched processing possible with
newspost (and I believe its front-ends).  If it gets full batch
processing, it will most likely be built-in, or using a library (so part
of the same binary in memory, if not on disk), rather than support for a
separate executable binary.

That is, of course, unless someone happens to supply patches ready to go
implementing that functionality...

At present, the big project underway is the conversion of the back-end
database to SQLite, and along with it, reimplementation of much of the
overview handling code, allowing PAN to scale FAR better than it can
currently, by combining multiple instances of common strings such as
author and/or subject lines, and allowing PAN to only keep a limited
number of overviews in memory at once, instead of having to keep ALL
overviews available for a group in memory together. PAN currently becomes
unmanageable at several hundred thousand overviews per newsgroup, even
with a full gig of memory to use. The new code should allow that to scale
into the millions of overviews, and possibly virtually unlimited, since
it'll only keep a segment of the group in memory at any one time, rather
than the entire thing, as is done now.  The database handling and backend
work is designed to make that possible, as the way PAN handles things now,
it HAS to keep the entire group in memory, due to the way it's coded, or
group refresh wouldn't work correctly.

The backend and database work will also make adding fully automated
multi-server support, where PAN will automatically download from all
servers from which you've subscribed to a particular group, at the same
time, instead of forcing the user to queue downloads separately for each
server, a trivial job.  It may or may not be in the first edition with the
new backend, but once the backend is implemented and generally debugged,
adding fully automated-multiserver support will, as I said, be fairly
trivial, because the implementation is being redesigned with that in mind
as well.  Thus, the only biggest reason /not/ to add that functionality
immediately would be to allow the new backend code to stabilize a bit
before adding the multiserver code to it, so both sets of functionality
wouldn't be being debugged at the same time.

If you want to try the PAN-CVS version, you can see how the work is coming
along.  It'll probably be late this year before a beta release, and at
least early next year, maybe mid-year or possibly even later, before the
new code stabilizes enough to have a stable release.  At that point, it'll
be time to reassess the situation and see what makes sense to work on
next.  It might be binary posting.  It might not.   Thus, you are looking
at very roughly another year, before binary posting in any form is likely
to be considered again, and that's assuming work continues.  (Charles took
about a year to year and a half off, not doing much with PAN over that
time, due to being to busy with "real life".  He's back now, but the point
is, PAN development is something he does in his spare time, not something
anyone has offered to pay him to work on, so...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html






reply via email to

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