Re: Enhanced virtual groups

[James Leifer <James.Leifer@inria.fr>]

David Moore <dmoore@caida.org> writes:

<snip>

> I've been thinking about just this problem recently, and am likely to
> modify nnvirtual to allow these sorts of things more easily/efficiently.
> The poor man's way of doing some of it now is to have a big nnvirtual
> group and using limiting to narrow things down.

Hi David,

That's great that you're thinking of improving nnvirtual!

I'd be really happy to have google gmail (or evolution) like
functionality for gnus to handle my 100,000+ messages.  Here are some
ideas on what we would need in order to do this.

The specification of the contents of a virtual group is rather simple:

   (
     ("mygroup1" (100 101 (102 . 107)))
     ("mygroup2" (20506))
   )
   ...

i.e. a list of pairs, where each pair consists of 

* an underlying group name;

* a list of article numbers from that group.

There are a couple of important properties of the constructed virtual
group

* mnimal retrieval

  The virtual group should retrieve only the articles from the
  underlying groups that are requested; e.g. if we have a virtual
  group consisting of 5 articles from my inbox of 50K articles, the
  retrieval should be almost instantaneous.

* mark pulling

  The virtual group's articles should inherit the marks of the
  underlying groups; e.g. if the virtual group includes article 31415
  from my inbox and this article was marked read in my inbox, it
  should be marked read in the virtual groups.

* mark pushing
 
  The virtual group should push mark changes back onto the underlying
  groups; e.g. replying to an article in the virtual group should push
  the reply mark onto the article in the underlying group.

This would give us some wonderful capabilities.  For example, we could
use indexing tools such as swish++ to rapidly assemble a list of
articles (spanning several underlying groups) which could be
aggregated into a virtual group.  Also, we could take any article in
the virtual group and "expand" it into a new virtual group to include
its complete surrounding thread (provided that external indexing tools
or the gnus registry could provide this data).

Comments?

-J