Re: Discussion: To del cached articles upon zapping group info?

[David Moore <dmoore@UCSD.EDU>]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> IMHO, I think the negative numbers scheme is the best solution. It completely
> hides the problem from the user, and old cached articles will still appear in
> the newsgroup that you cached them in. It's very neat and tidy.

	I'm preferring the negative number scheme myself.  If you make
another directory for the old articles but still want them to appear
with the articles from the new server, you'd need to place a virtual
group on top of them.  I'm not too concerned about the performance of
doing this, but it makes maintaining your newsgroups a lot more
difficult.  You have files in multiple trees; every original newsgroup
is now 3 newgroups (1 old cache, 1 new nntp, 1 new virtual), etc.  Even
if you made the virtual groups dynmically without explicitly being in
the newsrc. you'd need to be careful about people's hooks checking the
method vs nntp and similar.

	Whereas if everything stays in the same cache file, but with
negative numbers for articles (-1..-N for N articles in orig cache), you
don't have to change any of the rest of your group setup (creating these
extra groups).

	Most things in the code would work fine if this change was made,
except a couple routines which filter out negative numbers in ranges, I
think.  Changing those to just filtering numbers outside of the
'cache+nntp' active range, as done in most other places should hopefully
make everything work.  But then, there might be some hidden dependencies
on the article numbers being positive that I'm missing.

	Another approach would be to put the articles in the cache
numbered 1..N, and store the delta N as a group parameter, and then just
add N to all article numbers returned by the backend for that group.
This adds more overhead to article fetching, and makes Xref's rather
challenging.

	Or you could let article numbers (internally to gnus) come as
dotted pairs: (component-number . article-number).  And you'd just
assign increasing component-numbers to each new nntp server you get.
Going this path means changing a lot more internal code, but you might
be able to leverage the functionality for nnvirtual and IMAP.  Although,
it's probably not worth it. ;)


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!