🚀 go-pugleaf

In article <KPC.92Dec24181925@zog.arc.nasa.gov> kpc@ptolemy.arc.nasa.gov writes:
>here's what i think is necessary to implement virtual newsgroups in
>gnus.

When I initially purposed vgr's about a year and half ago I ment to make a 
reader independant method of making the virtual article base and then leave it
up to the reader on how to use that db.

>a virtual newsgroup has a name and constituent newsgroups.  "emacs"
>might be the name of a virtual group, and gnu.emacs.help,
>gnu.emacs.vm.bug, and gnu.emacs.gnus might be the constituents.

This is a postive and a negative.  A user may want to varei the set of
member groups dynamically.  For example the have a group called best_of which
reads alt.best.of.usenet, but if I read an article in it, it will automatical
expand the searchable articles to include the originating group.

Also how will you handle large sets of groups such as alt.*.

>make followups look at the newsgroups line to see what newsgroup to
>post to.  if it's ambiguous, ask the user.

Basically good but the vgr portion of the system should learn what goes where
pretty soon.  An other possible solution is to get rid of newsgroups and use
vgr's to make custom ones.

>make the default save file be the virtual newsgroup name.  i have
>code for this part.

Fair enough but this should be configurable, either savable to the vgr name or
to the newgroup line setting.

>make the kill file be the virtual newsgroup name.

vgr's are the opposit of kill files so I don't see how this one works.  Maybe
what you call a vgr is very different then what I call them I define a vgr
as being a way to select what you want to see not get rid of things you don't
want to see you do this by a set of rules.

>put the virtual newsgroup name in the newsgroups buffer just as if it
>were a real newsgroup.

This might lead to confusion but it does make the most sense interms of smooth
integration into the existing struct.

>use an alist to provide correspondences between virtual newsgroups and
>their constituents.

The rules should specify this yes but the user should be able to fine tone it
in real time.
-- 
Aryeh Friedman,Co-Pre&CTO,WorldNet Communications,P.O.26785,Tempe,AZ,85285-6785.
"Any manner of getting money that doesn't send you to jail is a valid way to 
fund a company" -- Wes Harker Disclaimer: I don't usually speak for my company.
Though it does at times try to speak for me.E-mail:aryeh@cash.ucsc.edu

i found your followup very confusing, probably because i didn't
explain what a virtual newsgroup is in my article (i explain it
elsewhere and just said what would be necessary to implement them).

it sounds like you have an idea for gnus called "vgr".  these are
probably very different from virtual newsgroups.  they might be a good
idea to work on separately or after virtual newsgroups are implemented.

virtual newsgroups are pretty simple.

virtual newsgroups are a mapping, using just an alist at first (we can
worry about automatic adding and deleting from the alist later) from
newsgroup names to a user-defined name.  they don't have to follow
hierarchies.  i can put "alt.lucid-emacs.help" in my emacs virtual
newsgroup.  the important thing is that the newsgroups buffer doesn't
get cluttered with newsgroups; just the topics you want are in there.

and when you hit spc, you get a subject buffer with all of the
articles in the newsgroups.  for example, i hit spc on "emacs" and i
get this article, your article, jwz's lemacs posts, etc.

there are embellishments, of course, such as having keys that modify
the alist and save it, having partial inclusion in a newsgroup, etc.
(you can use a special kill setup to say what subjects in various
newsgroups get included in the virtual newsgroup, and so on).  but
that's for later.  a long time ago i wrote about "simple" and
"complete" virtual newsgroups (i might have used different terms).
what i'm suggesting here is "simple" virtual newsgroups.

i think the implementation shouldn't be too hard; just put all the
articles in one subject buffer and figure out where to get an article
from when you hit spc.

In article <1hnhfeINNa7g@darkstar.UCSC.EDU> aryeh@cash.ucsc.edu (Aryeh Friedman) writes:

        if I read an article in it, it will automatical
   expand the searchable articles to include the originating group.

sounds like maybe you are suggesting that crossposts and reposts
automatically increase the set of newsgroups?  that's a feature that
you can build on top of virtual newsgroups if you want, if that's what
you mean.

   Also how will you handle large sets of groups such as alt.*.

that's an open-ended question (is it a question?).  i don't know what
you mean.  maybe you think virtual newsgroups have something to do
with hierarchy?  they don't.  for example, you can have one alt group
and one gnu group in a virtual newsgroup if you want.

   Basically good but the vgr portion of the system should learn what goes where
   pretty soon.  An other possible solution is to get rid of newsgroups and use
   vgr's to make custom ones.

i'd be delighted if a learning component were added at the newsgroup
level.  i still don't know how vgr works, but if you'd like to write
it, that would be great.  would this be on top of or separate from
virtual newsgroups?

   I define a vgr
   as being a way to select what you want to see not get rid of things you don't
   want to see you do this by a set of rules.

it sounds like vgrs have nothing to do with simple virtual newsgroups.
selecting subjects you want is a completely different matter.
(although complete virtual newsgroups would probably meet your needs
in effect by including subjects regardless of their originating
newsgroup, i'm more concerned about getting the simple basics of
making a superset newsgroup done first.)

   >use an alist to provide correspondences between virtual newsgroups and

   The rules should specify this yes but the user should be able to fine tone it
   in real time.

good idea to use rules and allow the user to edit the alist.  but
that's for later.  for now, why don't we just use an alist so that we
can get the basic mechanism working....
-- 
i'm open to comparing research career notes with other cogsci/cogneuro people.