5.4.13 and virtual servers

5.4.13 and virtual servers

[Sudish Joseph]

This is what I see:

Opening nntp server on tabloid...
Opening nntp server on tabloid+nntp+tabloid:internal.lists.freebsd.hackers...
Opening nntp server on tabloid...
Opening nntp server on tabloid+nntp+tabloid:internal.lists.emacs.gnus...
Opening nntp server on tabloid...
Opening nntp server on tabloid+nntp+tabloid:internal.engineering.cvs...
Opening nntp server on tabloid...
Opening nntp server on tabloid+nntp+tabloid:internal.beta...
Opening nntp server on tabloid+nntp+tabloid:internal.general...
Opening nntp server on tabloid+nntp+tabloid:internal.gossip...
Opening nntp server on tabloid+nntp+tabloid:internal.newbiz...
Opening nntp server on tabloid+nntp+tabloid:internal.sales...
Opening nntp server on tabloid+nntp+tabloid:internal.sports...
Opening nntp server on tabloid+nntp+tabloid:internal.test...
Opening nntp server on tabloid+nntp+tabloid:internal.lists.nanog...

0.82 didn't (re)open servers so often.  Is this just an
overenthusiastic 'message?

Has the server name format changed?  AFAICR, the virtual server
"tabloid" has always been known as "nntp+tabloid"--there now seems to
be a redundant prefix.

-Sudish

Re: 5.4.13 and virtual servers

[Sudish Joseph]

Sudish Joseph writes:
> This is what I see:
[ bunch of redundant "opening server"'s deleted ]

> 0.82 didn't (re)open servers so often.  Is this just an
> overenthusiastic 'message?

Nope.  I show 12 TCP connections open to the virtual server.  There're
just two open to the primary select method, as expected.

-Sudish

Re: 5.4.13 and virtual servers

[Lars Magne Ingebrigtsen]

Sudish Joseph <sj@eng.mindspring.net> writes:

> > 0.82 didn't (re)open servers so often.  Is this just an
> > overenthusiastic 'message?
> 
> Nope.  I show 12 TCP connections open to the virtual server.  There're
> just two open to the primary select method, as expected.

Yes, nntp now opens a connection per virtual server.  I don't know how
else to make things work cleanly.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: 5.4.13 and virtual servers

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Yes, nntp now opens a connection per virtual server.  I don't know how
> else to make things work cleanly.

Whatever mechanism was in place before, as of approx 5.4.8 and
previous, was better, if not as clean in some sense.  It was about
that time that the many-opens symptom began to occur.  Backing out to
that behavior, even if it left bugs somewhere else, would be
preferable.

Perhaps this could be related to how one introduces new groups to
Gnus.  I use 4 servers: My primary (general discussions) is at CMU,
and then I use one at Ohio State for about 5 groups, 1 here at JPRC
for local support groups, and 1 on my own system which is a test
server for INN hackery.  When I want a new group, I always generate it
with "G m some.name RET nntp RET server.name RET".  Does this generate
a new virtual server each time?  Would going into server mode via `^'
allow creation of groups with a single virtual server?  If so, how and
why does this differ from `G m' creation?

Re: 5.4.13 and virtual servers

[Felix Lee]

related gripe.

I'm not too thrilled with gnus's structure of
  group list
    group
      server for group

I've got 4 or so nntp servers I'm interested in, with dozens
of groups from each server that I'd like to look at.

I'd much rather gnus had a structure like:
  server
    group list
      group 

but this is probably too major a structural change.  yes?

(netscape's news widget has this structure, but otherwise
it's pretty mediocre.)
--

Re: 5.4.13 and virtual servers

[Paul Franklin]

>>>>> Felix Lee writes:

 > I'd much rather gnus had a structure like:
 >   server
 >     group list
 >       group 

 > but this is probably too major a structural change.  yes?

There are two ways I can see to do this:

* Using current Gnus:

  Use topics, one topic per server.  This gets you _almost_ what you
  want; you'll have to expand/unexpand topics on your own, and use M-g
  on a topic to get new news.

* Enhancements to Gnus:

  Add two commands:

  * gnus-servers (gnus-start-server-buffer?)--enters Gnus and goes
    straight to the server buffer, without opening any connections to
    servers first.

  * gnus-server-read-server-newsrc--produces a buffer very similar to
    the group buffer, but with only groups from that server listed;
    quitting this buffer returns to the server buffer.

Lars, the first command might be useful in any case; marking servers
as denied has been much more successful for dealing with problematic
servers than using gnus-no-server.

--Paul

Re: 5.4.13 and virtual servers

[Albrecht Kadlec]

Paul Franklin <paul@cs.washington.edu> writes:

> >>>>> Felix Lee writes:
> 
>  > I'd much rather gnus had a structure like:
>  >   server
>  >     group list
>  >       group 
> 
>  > but this is probably too major a structural change.  yes?

strongly seconded, but probably mucho work.


>   * gnus-servers (gnus-start-server-buffer?)--enters Gnus and goes
>     straight to the server buffer, without opening any connections to
>     servers first.

IMHO, this should also be the default, if gnus-select-method is nil.
currently gnus signals an error.

there's a amazing variety of possibilities, but they could really do with
some boiling down, so one can overlook them again.

>   * gnus-server-read-server-newsrc--produces a buffer very similar to
>     the group buffer, but with only groups from that server listed;
>     quitting this buffer returns to the server buffer.
not at all the same

albrecht

Re: 5.4.13 and virtual servers

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@jprc.com> writes:

> > Yes, nntp now opens a connection per virtual server.  I don't know how
> > else to make things work cleanly.
> 
> Whatever mechanism was in place before, as of approx 5.4.8 and
> previous, was better, if not as clean in some sense.  It was about
> that time that the many-opens symptom began to occur.  Backing out to
> that behavior, even if it left bugs somewhere else, would be
> preferable.

Yes, the current situation is kinda yucky.  Going back to something
that's actually buggy doesn't seem like a good idea, though.  

> Perhaps this could be related to how one introduces new groups to
> Gnus.  I use 4 servers: My primary (general discussions) is at CMU,
> and then I use one at Ohio State for about 5 groups, 1 here at JPRC
> for local support groups, and 1 on my own system which is a test
> server for INN hackery.  When I want a new group, I always generate it
> with "G m some.name RET nntp RET server.name RET".  Does this generate
> a new virtual server each time?

It shouldn't, but it might if there's (wow!) a bug in the new function
that compares servers.  Let's see...  Find two groups created in this
manner (that use the same server), and pick out the select methods
with `G e' on the two groups.  Then do

(gnus-server-get-method GROUP METHOD)

an both these groups (with their server) and see what it says.  It
should ideally return the same method for both groups.

> Would going into server mode via `^' allow creation of groups with a
> single virtual server?

Yes.

> If so, how and why does this differ from `G m' creation?

`G m group RET server RET'.  So it's would be less typing in the long
run. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: 5.4.13 and virtual servers

[Lars Magne Ingebrigtsen]

Paul Franklin <paul@cs.washington.edu> writes:

> * Enhancements to Gnus:
> 
>   Add two commands:
> 
>   * gnus-servers (gnus-start-server-buffer?)--enters Gnus and goes
>     straight to the server buffer, without opening any connections to
>     servers first.
> 
>   * gnus-server-read-server-newsrc--produces a buffer very similar to
>     the group buffer, but with only groups from that server listed;
>     quitting this buffer returns to the server buffer.
> 
> Lars, the first command might be useful in any case; marking servers
> as denied has been much more successful for dealing with problematic
> servers than using gnus-no-server.

Hm...  I think the former wouldn't be that useful without the latter.
So perhaps we should do both?  We'll see.  I've now added this to the
todo list.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: 5.4.13 and virtual servers

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> It shouldn't, but it might if there's (wow!) a bug in the new function
> that compares servers.  Let's see...  Find two groups created in this
> manner (that use the same server), and pick out the select methods
> with `G e' on the two groups.  Then do
> (gnus-server-get-method GROUP METHOD)
> an both these groups (with their server) and see what it says.  It
> should ideally return the same method for both groups.

OK, I picked on my local INN-hackery server's instance of
news.admin.{misc,technical}.  I know they cause distinct server opens
due to *Message-Log*:

Opening nntp server on localhost+nntp+localhost:news.admin.misc... 
Opening nntp server on localhost+nntp+localhost:news.admin.technical... 

`G e' for both groups returns an edit-form buffer with this content:

(nntp "localhost" 
      (nntp-address "localhost")) 

Then executing, e.g.,
	(gnus-server-get-method "news.admin.misc"
				'(nntp "localhost" (nntp-address "localhost"))
returns in the minibuffer:

(nntp "localhost" (nntp-address "localhost")) 

(Seems kinda redundant, but I think that's what you wanted.)

Identical responses for both.  One would presume they compare as
equivalent.  Um...unless they don't use the string= function?  Um,
gnus-server-get-method calls get-server-to-method, and there it loops
through the opened servers, looking for a match with `equal' rather
than `string='.  Is this the problem?

> > If so, how and why does this differ from `G m' creation?

> `G m group RET server RET'.  So it's would be less typing in the long
> run. 

I suppose I didn't ask the question very precisely.

Obviously, I can type X characters to create a group via `G m', or I
can type Y characters via entry to server mode, poke around the group
list, and subscribe those I like.

What I'm wondering is whether two groups defined only via `G m' would
have some relevant server difference indicated in the forms one finds
in .newsrc.eld, or whether a group selected via server-mode would
differ from one defined via `G m', assuming that the names typed (etc)
are the same.

Re: 5.4.13 and virtual servers

[David Moore]

Karl Kleinpaste <karl@jprc.com> writes:

> Opening nntp server on localhost+nntp+localhost:news.admin.misc... 
> Opening nntp server on localhost+nntp+localhost:news.admin.technical... 
> 
> `G e' for both groups returns an edit-form buffer with this content:
> 
> (nntp "localhost" 
>       (nntp-address "localhost")) 

3 of my mail groups magically obtained: (nnml "email" (nnml-address
"email")) 

I noticed extra servers a couple days ago, and finally got around to
looking at the defintions earlier this morning. Probably isn't older
than the past 2 weeks or so.  This is with 5.4.8 in XEmacs19.15 and
5.4.13 in XEmacs20.1.

-- 
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/>    | In a cloud bones of steel.

Re: 5.4.13 and virtual servers

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@jprc.com> writes:

> Then executing, e.g.,
> 	(gnus-server-get-method "news.admin.misc"
> 				'(nntp "localhost" (nntp-address "localhost"))
> returns in the minibuffer:
> 
> (nntp "localhost" (nntp-address "localhost")) 
> 
> (Seems kinda redundant, but I think that's what you wanted.)

Yup.

> Identical responses for both.  One would presume they compare as
> equivalent.  Um...unless they don't use the string= function?  Um,
> gnus-server-get-method calls get-server-to-method, and there it loops
> through the opened servers, looking for a match with `equal' rather
> than `string='.  Is this the problem?

No, that should be ok.

What does the following eval to?

(gnus-server-equal
 (gnus-find-method-for-group "news.admin.misc")
 (gnus-find-method-for-group "news.admin.technical"))

> What I'm wondering is whether two groups defined only via `G m' would
> have some relevant server difference indicated in the forms one finds
> in .newsrc.eld, or whether a group selected via server-mode would
> differ from one defined via `G m', assuming that the names typed (etc)
> are the same.

Yes.  If you give a virtual server as the select method, only the
server name will be stored in the group info.  If you give a backend
name and a server name, the select method itself will be stored in the
group info.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: 5.4.13 and virtual servers

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> What does the following eval to?
> (gnus-server-equal
>  (gnus-find-method-for-group "news.admin.misc")
>  (gnus-find-method-for-group "news.admin.technical"))

`t'

> Yes.  If you give a virtual server as the select method, only the
> server name will be stored in the group info.  If you give a backend
> name and a server name, the select method itself will be stored in the
> group info.

OK, then I will stop creating nntp groups via `G m'.  That will take a
bit of pain, but it's what I should have done in the 1st place.