Re: [Pan-users] Re: Re: Re: Re: Re: Fit image to Window

[Mike Brodbelt]

Duncan wrote:

> I've thought along those lines myself. If you look at the goals and the
> original name, "Pimp Ass Newsreader",  PAN has a quite a way to get to
> where it can really claim to have met that.

Indeed - there are a few things up there that would be nice.

> What I've wondered if happened, was that (probably originally b4 Charles,
> with the original developer, check the credits) PAN quickly became better
> than most other Linux alternatives, with what was never intended to be any
> more than preliminary "demo" code.

The first version of Pan I used was 0.5, or 0.6 I think. It was
unstable, and quite irritating to use sometimes, but even then it was
what I was lookig for more than any of the alternatives. Reading Usenet
on Linux back then pretty much required you to set up a local NNTP
server, and then point an online reader at that. I used Netscape 4 with
leafnode, sometimes Tin, and occasionally Forte Agent under Wine, which
worked(ish). As Pan got more stable I rapidly found myself using it
almost exclusively - it let me read news without bothering with new
servers and things, and provided a better GUI than anything else.

So, to get round to the point, I think Pan probably grew users faster
than anticipated - it hit the right spot on the effort/reward curve for
a lot of people.

<snip>

> If that were even somewhat the case, it would explain a lot of stuff,
> including PAN's scalability problems, as well as the apparent loss of
> interest or anyway priority of the lead developer, when he eventually
> discovered he was "mired in quicksand" due to all those users, and that it
> was no longer "fun" because the original goal to which he had aspired
> looked to now be out of reach.
> 
> Not being that lead developer, I of course cannot say that such HAS been
> the case, but it WOULD explain some things.

It's certainly more than feasible. I still think that the current
codebase has some life in it yet though. The thing to do would be to
gradually add an abstraction layer to the current code, separating the
GUI from the database. Glib provides all the primitives you'd need, and
if that could be done, then alternate storage backends could be
implemented, which would address the scalability issue.

Mike.