Subscription Question

Subscription Question

[Arnd Kohrs]

Hi,

while fiddling with a self-made backend, I experience the following
undesired behavior:

I have a server which is created in the server buffer and exposes like
the following upon pressing "e":

(nntmf "fool.com"
       (nntmf-address "boards.fool.com"))

When I subscribe to a group on this server and edit this group's select
method via "G e" i shows as follows:

(nntmf "fool.com"
       (nntmf-address "boards.fool.com"))

But this is undesired (and wrong I believe), and I actually would be
happier with

(nntmf "fool.com") 

(which is now achieved by editing the select method each time I
subscribe to a new group)

After some debugging sessions within the subscription mechanics of gnus
I am still clueless how to get there.  Maybe there is something to be
considered within the backend's code? And BTW what's the difference
between "nntmf:fool.com" and (nntmf "fool.com")? Hm this sounds like a
FAQ but anyway help is greatly appreciated.

Thanks,
Arnd.
-- 
Arnd Kohrs  -  Institut Eurecom - http://www.eurecom.fr/~kohrs
              
The Active WebMuseum: Your personalized access to art paintings.
 Visit now ->  http://www.eurecom.fr/~kohrs/museum.html

Re: Subscription Question

[Kai Großjohann]

On 08 Aug 2000, Arnd Kohrs wrote:

> 
> Hi,
> 
> while fiddling with a self-made backend, I experience the following
> undesired behavior:
> 
> I have a server which is created in the server buffer and exposes
> like the following upon pressing "e":
> 
> (nntmf "fool.com"
>        (nntmf-address "boards.fool.com"))
> 
> When I subscribe to a group on this server and edit this group's
> select method via "G e" i shows as follows:
> 
> (nntmf "fool.com"
>        (nntmf-address "boards.fool.com"))
> 
> But this is undesired (and wrong I believe), and I actually would be
> happier with
> 
> (nntmf "fool.com") 
> 
> (which is now achieved by editing the select method each time I
> subscribe to a new group)

No, you certainly don't want (nntmf "foo.com").  I think you want
"nntmf:fool.com". 

> After some debugging sessions within the subscription mechanics of
> gnus I am still clueless how to get there.  Maybe there is something
> to be considered within the backend's code? And BTW what's the
> difference between "nntmf:fool.com" and (nntmf "fool.com")? Hm this
> sounds like a FAQ but anyway help is greatly appreciated.

A server has a name and a value.  A value is a list (BACKEND NAME
PARAM...) where the first element gives the backend to use (ie, the
*.el file); the second element is a short string which is (part of)
the name of the server; the remaining elements are server parameters.
Each PARAM looks like (PNAME PVALUE) where PNAME is a symbol (similar
to a variable name) and PVALUE is a value (often a string, but
sometimes a number, can be anything, really).

The server name is constructed from the BACKEND and NAME parts of the
server value, like so: "BACKEND:NAME".  Here's a server value:

(nntmf "fool.com" (nntmf-address "boards.fool.com"))

This server is named "nntmf:fool.com".

Gnus remembers the server for each group (in the .newsrc.eld file).
Consider two groups:

Group "foo" has server value in .newsrc.eld file, group "bar" has
server name in .newsrc.eld.  Suppose you now edit the server
definition to point to a different nntmf-address.  The group foo will
still be read from the old host, but the group bar will be read from
the new host.

Note that there is redundant information in the .newsrc.eld file,
since the group name also contains the server name!  Group names like
"foo.bar" come from the native server (as of gnus-select-method), and
a group named "nnfoo+bar:blarfl.discuss" comes from the server named
"nnfoo:bar".

Of course, having this redundant information means that something is
bound to get confused because some parts of Gnus probably intuit the
right server from the group name, whereas other parts of Gnus get the
server from the .newsrc.eld entry.  Whee.

I think that something should be done about this.  But what?

kai
-- 
I like BOTH kinds of music.

Re: Subscription Question

[Arnd Kohrs]

>>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    Kai> On 08 Aug 2000, Arnd Kohrs wrote:
    >>  Hi,
    >> 
    >> while fiddling with a self-made backend, I experience the
    >> following undesired behavior:
    >> 
    >> I have a server which is created in the server buffer and exposes
    >> like the following upon pressing "e":
    >> 
    >> (nntmf "fool.com" (nntmf-address "boards.fool.com"))
    >> 
    >> When I subscribe to a group on this server and edit this group's
    >> select method via "G e" i shows as follows:
    >> 
    >> (nntmf "fool.com" (nntmf-address "boards.fool.com"))
    >> 
    >> But this is undesired (and wrong I believe), and I actually would
    >> be happier with
    >> 
    >> (nntmf "fool.com")
    >> 
    >> (which is now achieved by editing the select method each time I
    >> subscribe to a new group)

    Kai> No, you certainly don't want (nntmf "foo.com").  I think you
    Kai> want "nntmf:fool.com".

Now I figured out why the groups get subscribed with the method instead
of the server-name.

When a group is subscribed to gnus-browse-unsubscribe-group call
gnus-method-simplify to transform the method to a server-name.  However,
this works only for methods listed in gnus-secondary-servers and NOT for
methods created in the server buffer.  Bug or feature?  This question is
beyond me - since there is too much gnus design philosophy involved.

I guess this is a bug and gnus-method-simplify should try to look also
in gnus-opened-servers to find a server-name but that probably creates
some problems for volatile servers.

My resolution for the moment: Define lasting methods in
gnus-secondary-select-methods (not in the server buffer) to avoid
trouble.

Cheers,
Arnd.


-- 
Arnd Kohrs  -  Institut Eurecom - http://www.eurecom.fr/~kohrs
              
The Active WebMuseum: Your personalized access to art paintings.
 Visit now ->  http://www.eurecom.fr/~kohrs/museum.html

Re: Subscription Question

[Kai Großjohann]

On 09 Aug 2000, Arnd Kohrs wrote:

> My resolution for the moment: Define lasting methods in
> gnus-secondary-select-methods (not in the server buffer) to avoid
> trouble.

Yes, this sounds like a good idea.

kai
-- 
I like BOTH kinds of music.