Re: Re: Re: Couple of feature requests

Pekka Tiittanen <[email protected]>
posted 1151748373.5005.5.camel@smack, excerpted below, on  Sat, 01 Jul
2006 13:06:13 +0300:

> I only want to be able to subscribe to groups on different servers and
> download them from that one server only. Over here in Finland there's
> usually only one newsserver that can be used and that's the ISP's
> server. Using servers from different countries is usually slow so ISP's
> server is usually the best choice. So I don't see any good point for
> this new arrangement for making primary/secondary/etc servers.

Well, one thing I noted awhile back playing with klibido is that if it's
just because they are slow, not because one costs more than another, it
ends up more or less the way you want it anyway.  That is, the slow server
doesn't get a /chance/ to download more than say one out of ten parts,
because all the others are coming from the fast server.  You use up to the
limit of your pipe and can't use any more, so the fast server ends up
providing almost everything anyway.  The slow server only gets in a bit of
bandwidth now and then.

The same thing happens with completion.  Assuming servers more or less the
same speed, the server with the lowest completion ends up skipping more
parts because they aren't there to download, so gets way ahead of the
other one, so you get as many parts as possible from the one with the
least completion and naturally pickup from other servers only when the
low-completion one didn't have it.  IOW, it naturally works the way one
would normally want it to work, maximizing the possible efficiency, with
no need to artificially constrain things.

It follows that the only time one really has to bother with priorities is
where one server costs enough more than the others that you want to use it
as little as possible, either where it's significantly faster than others
available, so must be artificially constrained to keep nearly everything
from coming from it, or where you have good enough completion on another
server to keep it slow enough that the expensive server would get more
than absolutely needed use in the first place.

Actually, now that I'm thinking about it, that should apply to your
leafnode server as well. If it has the posts predownloaded, it's going to
be so much faster than the others that you'll naturally pull nearly
everything from it. Thus, there shouldn't be that much of a reason to
fiddle with its priority anyway, since it will naturally be the fastest
and therefore provide most requests where it has predownloaded them, and
naturally slow down dramatically where it hasn't, which would presumably
be when you'd want the posts from the other servers.

> And I really do want to control where my groups are downloaded from. Now
> after thinking this a while, would it be possible to make a per group
> setting "download this group only from server" with a dropdown menu of
> all the configured servers where to choose from? That'd solve my problem
> alltogether.

If that feature is added, it'll be post 1.0, because there's no per-group
general state retention (only message status, etc) at the moment at all.
Whether it'll make 1.1 or any particular version I can't say. In any case,
were the feature to be added, it would be a checkbox list, so more than
one group could be checked at a time, rather than a radiobutton list or
dropdown toggle where only one could be selected at once.

> Without that I don't see myself even trying out these weekly releases of
> Pan, 'cause they still don't give me anything new or better to test out.

That could well be your best choice at the moment.  Mainly those that want
to download from many servers at once, or are running into the memory
scaling issues with the old version, will ATM find the new pan worth
switching to.  If neither  applies to you, the older version is likely
your better choice. When per-group state returns, likely with the pre-1.1
betas, things may change, but ATM sticking with the old version is going
to be the better choice for many.  Of course, eventually the old version
will get crufty from lack of maintenance and there will be problems
keeping it working as the rest of the world moves forward.  However, with
luck and Charles' hard work, new pan will be usable enough for you by then
(post 1.1 almost certainly, maybe well beyond that, look at the folks,
myself included, still running GTK+ 1.x, for xmms, crufty as /it/ is) that
changing won't be a big deal.



-- 
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