[Pan-users] Re: Re: Using Newspost With Pan

[Duncan]

Old Rocker posted <address@hidden>,
excerpted below,  on Wed, 06 Oct 2004 05:15:39 +0100:

> If it's as easy as writing a script, couldn't newspost access be 
> included in a future version of Pan?  I'd really like that, and no 
> doubt others would too.

Well, it /could/ be.  Actually, one of the PAN betas had a
(non-functional) attachment selector front-end, and Charles said he had
the code for both it and the backend (that would have actually done the
encoding and attaching) at that time.  I don't really know why the
functionality wasn't added then, except that Charles mentioned it'd do
single-part only (and presumably one attachment at a time, no batch
posting capabilities at all).  Thus, I'd guess it may have come out
because it didn't fit in with Charles' idea of what a
"Pimp-Ass-Newsreader's" posting functionality should be like.  When the
attachment browsing front-end appeared and disappeared, it naturally
sparked a discussion, and if I read Charles' opinion correctly, he had
decided that the time wasn't right for adding the functionality (and
having to debug it in the next couple betas at least) and that it should
wait.

Personally, the front-end looked great to me.  Sure, attaching a file at a
time wouldn't go far toward full batch posting or multi-part posting, but
it would have been better than what we have now.  I can however see the
possibility of a concern that it might be just "good enough" so PAN never
did get "proper" posting functionality.  I was thinking about that a
couple weeks ago.  I think PAN quickly got "good enough" in general, and
better (for its class, graphical Linux newsreader that displays pix in
place) than the alternatives, that it got a large user-base faster than
intended.  Unfortunately, there hasn't been a huge amount of contribution,
either monetarily (Charles remarked at one point that he'd gotten IIRC all
of $16 from that tip jar) or in like -- code returned to the project. 
Numbers of folks have contributed patches, but it just hasn't developed
the coder-support base to grow as fast as early developers may have hoped.
For quite some time it was Charles and Chris only.  Anyway, without
serious coding contribution, and with a fairly large user base meaning one
couldn't really tear into things and radically modify existing working
code any more, to get PAN to where it was ultimately intended to go (as
mentioned, to be a seriously "Pimp-Ass Newsreader"), development slowed
and (I'm guessing) Charles ultimately found something more interesting
(and bill paying) to do with his time.  Thus (and this is speculation
on my part), perhaps Charles didn't want to repeat the effect with posting.

However.. now we have a news client frozen in time for nearly a year since
the last beta (Jan 2004), and with slow development for another half a
year before that.  That's a year and a half of standing still while the
rest of the world moves on.  Don't get me wrong.  I'm definitely grateful
for what Charles and Chris (and the earlier authors, Matt and Jason, altho
I arrived after their tenure AFAIK) have given us, particularly since they
have the coding skills I don't.  However, as Eric Raymond said in the book
"The Cathedral and the Bazaar" (don't remember which essay), the
ultimately last job of any open source developer, once he's lost interest
or the time or other resources to continue to properly lead a project he
leads, is to find someone else to take it over.  I don't know if Charles
has looked in that direction and not found anyone willing and suitable, or
continues to believe he'll get back to PAN, but at a year on, it's
beginning to look like he/we should be considering something of that
nature.

That said, one of the things that /had/ begun to hold up development was
the fact that PAN is in serious need of a database library (such as
SQLite) backend (the idea being to implement the dblib much as PAN
implemented GNET as its networking lib), so it can scale to more than a
million or so overviews per group, and so that additional "super-features"
such as fully automated multi-server handling (a la BNR2) could build on
that backend.  Charles isn't a db programmer, and it seemed to me he was
always a bit uncomfortable and hesitant when discussing doing that
implementation.  The nearly frozen mainline tree /has/ encouraged several
folks that /are/ db hackers to get involved and code up their own
implementations toward that end.  It's quite (likely? possible?) that when
PAN /does/ again come under active development in the main tree, one of
these will be nearly ready to "drop in".  If that proves to be the case
and a db backend goes mainline right away after development resumes, as I
mentioned, it opens the door to /all/ /sorts/ of additional possibilities,
and a very real chance for PAN to really fulfill all that its original
name points to as a goal and promise.  Thus, I do remain seriously
hopeful.  

As well, that's the reason I've hesitated before looking much elsewhere,
as I can envision just getting comfortable with my new news client only to
read about how the one I just deserted is taking off! <g>  Still, given
the rate at which open source in general develops, a year and a half with
little activity... can /very/ easily mean something else that /used/ to be
way behind has now well passed you by...  IMO, /something's/ going to
happen in the next year.  Either PAN development will pick up again, or
it's likely many distribs may decide it's a dead project, and it will be
dropped from more and more of them.  Of course, that isn't real likely to
happen to a huge degree unless a security vuln is found or GTK or some
other element PAN depends on evolves into an incompatible version and PAN
doesn't follow, in which case the folks that make the decisions will look
at the site and see there hasn't been much activity in what by then will
be two years, and decide /they/ don't want to have to support it, and that
will be the end in terms of new deployments and users.  (I follow the
Gentoo devel list and see remarks of this sort.. "CVS hasn't had any
activity to speak of in a year and a half, and it doesn't currently
build, so unless anyone has any huge objections and agrees to take
over maintainership of the package, it will be masked in 48 hours, and
removed in 30 days"... all the time.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin