[Q] primary / secondary methods differences

[Q] primary / secondary methods differences

[Didier Verna]

        Out of curiosity, does anybody know if the primary method and the
secondary ones behave exactly the same way (specification syntax, behavior
etc). Like, are there people using the primary for mails and stuff like that.


Thanks

-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: [Q] primary / secondary methods differences

[Kai Großjohann]

On 22 May 2001, Didier Verna wrote:

> Out of curiosity, does anybody know if the primary method
> and the secondary ones behave exactly the same way
> (specification syntax, behavior etc). Like, are there people
> using the primary for mails and stuff like that.

If you can do (add-to-list 'gnus-secondary-select-methods FOO), then
you can also do (setq gnus-select-method FOO), and vice versa.  Was
this what you meant?

Of course, primary and secondary methods do not work in the same way:
when displaying groups, the prefix is omitted for primary (native)
groups.

kai
-- 
~/.signature: No such file or directory

Re: [Q] primary / secondary methods differences

[Didier Verna]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

> If you can do (add-to-list 'gnus-secondary-select-methods FOO), then
> you can also do (setq gnus-select-method FOO), and vice versa.  Was
> this what you meant?

        Yup.

        The idea behind my question was that the concept of primary /
secondary method is now really obsolete. We should have single
`gnus-select-methodS' variable, and `gnus-no-server' shouldn't rely on levels
(which is also a misfeature), but instead, let you select which of your
gnus-select-methods you want to open for this session.

        Implementing `gnus-select-methods' while maintaining backward
compatibility doesn't look too difficult to me. I'm more sceptical on the
latter point though.

-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: [Q] primary / secondary methods differences

[Kai Großjohann]

On 22 May 2001, Didier Verna wrote:

> Implementing `gnus-select-methods' while maintaining backward
> compatibility doesn't look too difficult to me. I'm more sceptical
> on the latter point though.

How should it deal with the prefix/no prefix problem?  Maybe it's a
good thing to always have a prefix for the group names, but if you
treat the first entry in gnus-select-methods differently, you're back
to square one.

kai
-- 
~/.signature: No such file or directory

Re: [Q] primary / secondary methods differences

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> On 22 May 2001, Didier Verna wrote:
> > Implementing `gnus-select-methods' while maintaining backward
> > compatibility doesn't look too difficult to me.
> 
> How should it deal with the prefix/no prefix problem?

Prefixes are already configurable, and should remain so.  I can't
remember how I did it, but I got rid of the prefixes for groups on my
secondary server.  Unless you subscribe to the same group on multiple
servers, this doesn't introduce ambiguity.

Maybe elements of gnus-select-methods could have a face element, so
that the group buffer could indicate which groups belong to which
server, but without taking up extra space.  Or maybe not.


paul

Re: [Q] primary / secondary methods differences

[Didier Verna]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

> On 22 May 2001, Didier Verna wrote:
> 
> > Implementing `gnus-select-methods' while maintaining backward
> > compatibility doesn't look too difficult to me. I'm more sceptical
> > on the latter point though.
> 
> How should it deal with the prefix/no prefix problem?  Maybe it's a
> good thing to always have a prefix for the group names, but if you
> treat the first entry in gnus-select-methods differently, you're back
> to square one.

        Yup. Actually, I don't find the primary group dynamic selection
useful. At least, not if we provide a more general server selection scheme at
startup (I don't see how one would find that skiping the prefix is an
obsolutely necessary feature...).

        As far as backward compatibility is concerned, what we could do if
make gnus accept a nil primary method, and then use
`gnus-secondary-select-methods' as my `gnus-select-methods' variable. Then, we
could have a `gnus-select' function understanding the numeric prefix
convention, but also letting you choose the methods you want to enable at
startup.

        The important idea is to separate the notions of selection by level /
selection by server.

-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: [Q] primary / secondary methods differences

[Paul Jarc]

Didier Verna <didier@lrde.epita.fr> writes:
>         As far as backward compatibility is concerned, what we could
> do if make gnus accept a nil primary method, and then use
> `gnus-secondary-select-methods' as my `gnus-select-methods'
> variable.

How about: check gnus-select-methods; if it's non-nil, use it;
otherwise, use (cons gnus-select-method gnus-secondary-select-methods)?
Eventually, gnus-select-method and g-s-s-m might be removed.  g-s-s-m
would become a confusing name if it lists all the servers.

What about foreign servers?  A while ago, I think someone suggested
there should be only a single list of servers, customizable via the
server buffer.


paul

Re: [Q] primary / secondary methods differences

[Didier Verna]

prj@po.cwru.edu (Paul Jarc) wrote:

> How about: check gnus-select-methods; if it's non-nil, use it;
> otherwise, use (cons gnus-select-method gnus-secondary-select-methods)?

        Yup, that's better.

> What about foreign servers?  A while ago, I think someone suggested
> there should be only a single list of servers, customizable via the
> server buffer.

        It's good to have native servers different from foreign servers. I
find it important that gnus does not check for new newsgroups on foreign ones.

-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: [Q] primary / secondary methods differences

[Kai Großjohann]

On 22 May 2001, Didier Verna wrote:

> The important idea is to separate the notions of selection by level
> / selection by server.

This is clearly a Good Thing.

kai
-- 
~/.signature: No such file or directory

Re: [Q] primary / secondary methods differences

[Paul Jarc]

Didier Verna <didier@lrde.epita.fr> writes:
>         It's good to have native servers different from foreign
> servers. I find it important that gnus does not check for new
> newsgroups on foreign ones.

Maybe each server should have its own subscribe-newsgroup-method,
then.  It'd be nice if all servers were created equal, so to speak;
this doesn't mean we can't give them different attributes.


paul

Re: [Q] primary / secondary methods differences

[Didier Verna]

prj@po.cwru.edu (Paul Jarc) wrote:

> Maybe each server should have its own subscribe-newsgroup-method, then.

        Yes, I've thought about this several times indeed.


-- 
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org

Re: [Q] primary / secondary methods differences

[Simon Josefsson]

Didier Verna <didier@lrde.epita.fr> writes:

> > What about foreign servers?  A while ago, I think someone suggested
> > there should be only a single list of servers, customizable via the
> > server buffer.
> 
>         It's good to have native servers different from foreign
> servers. I find it important that gnus does not check for new
> newsgroups on foreign ones.

The foreignness of a server should IMHO just be a customization, it
should not define the server.  An enhanced *Server* buffer might list
all servers together with options and common operations:

  news                Backend: nntp      [DEL]
    Foreign: [ ]
    NNTP options:
      Address: news.example.org
      Port: nntp
      SSL [ ]

  mail                Backend: nnml      [DEL]
    NNML options:
      Directory: ~/Mail/
    NNML operations:
      [Regenerate NOV]
      
  imap.example.org    Backend: nnimap    [DEL]
    Foreign: [ ]
    NNIMAP options:
      Address: 
      Port: imap
      SSL [ ]
      Authenticator: [CRAM-MD5]

Or something.

Re: [Q] primary / secondary methods differences

[David S. Goldberg]

> Prefixes are already configurable, and should remain so.  I can't
> remember how I did it, but I got rid of the prefixes for groups on my
> secondary server.  Unless you subscribe to the same group on multiple
> servers, this doesn't introduce ambiguity.

Yes, but only for display.  Unless something's changed (I admit I
haven't tried this since I think it was quassia days)
gnus-group-jump-to-group, gcc headers et al require the fully prefixed
name, which I found to be confusing when the display didn't show the
prefixes.  I went back to the default display after I wanted to jump
to a group on one of three different servers and couldn't remember
which server it was on :-)
-- 
Dave Goldberg
dsg@world.std.com

Re: [Q] primary / secondary methods differences

[Kai Großjohann]

On 23 May 2001, Simon Josefsson wrote:

> The foreignness of a server should IMHO just be a customization, it
> should not define the server.

Maybe each server should have a `check-for-new-newsgroups' attribute.

kai
-- 
~/.signature: No such file or directory