Re: Gnus v5.4.62 is released

[Sudish Joseph <sj@eng.mindspring.net>]

Hrvoje Niksic writes:
> With the new default of `gnus-read-active-file' to `some', the killed
> list will never have been constructed in the first place.

I guess I missed that setting.  Note that the killed-list only needs
to be setup once -- I run with g-r-a-f set to 'some and g-s-k-l set to 
t.  The newgroups check suffices to keep it in synch with the server.

> A practical reason is that there are people trying to run Gnus in a
> multiuser environment, where they have a quota.  The size of
> .newsrc.eld can matter to them.

IMO we shouldn't cripple functionality to help an unknown problem with
disk quotas.  The user is the only one who knows what she needs, let
them make the decision to forgo functionailty for disk space.

>> OTOH, the thing about save-killed-list that annoys me most is the
>> additional time taken to save .newsrc.eld.  We can address that in
>> other ways than to default to not saving killed-list.

> How?

See below.

>> Since it's largest component is the list of killed groups, and since
>> that list is changed infrequently, it could be split out to a
>> separate file (which could even be loaded only on demand, if
>> needed).

By saving it only when it's changed.

> Here you have touched a separate issue, which is caching of
> server-side data.  For instance, Gnus might be much more useful if it
> cached things like newsgroups list, newsgroup descriptions, and even
> XOVER info, locally (Netscape 4 newsreader caches XOVER).

Sure, it's a separate issue, but it's one that's relevant to the
subject here.  Of all the cacheable items, the active file is the only 
one that actually affects functionality.  The others are performance
hacks.  I'm not saying performance isn't an important consideration -- 
just that a crippled newsreader will turn away more new users.

-Sudish