Re: nnimap/nnagent troubles

Re: nnimap/nnagent troubles

[Sean Doran]

| I think Gnus should not store the full server; it should use the
| server name in all places.  What do you think?

Having had to clean up after this a couple times recently by editing
.newsrc.eld directly after making some errors in my experimenting with
nnimap, I fully agree.

| (Of course, the sole exception is gnus-secondary-select-methods if set
| by the user, or the list of servers as per the server buffer.)

Yeah.

	Sean.

Re: nnimap/nnagent troubles

[Christoph Rohland]

Simon Josefsson <simon@josefsson.org> writes:

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

> > (Of course, the sole exception is gnus-secondary-select-methods if
> > set by the user, or the list of servers as per the server buffer.)
> 
> IMHO there should only be one list of servers, and it should be
> customized, and the server buffer should be a customized
> viewer/editor of that variable.  It should be aware of common server
> variables too (SSL, Kerberos, etc).

Yeeesss!!!

        Christoph

Re: nnimap/nnagent troubles

[Kai Großjohann]

On 08 Sep 2000, Simon Josefsson wrote:

> IMHO there should only be one list of servers, and it should be
> customized, and the server buffer should be a customized
> viewer/editor of that variable.  It should be aware of common server
> variables too (SSL, Kerberos, etc).

Good idea!  (Of course, coming from you!)

kai
-- 
I like BOTH kinds of music.

Re: nnimap/nnagent troubles

[Simon Josefsson]

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

> > Since Gnus store the full server in various places (in every group
> > info, in agent etc)
> 
> I think Gnus should not store the full server; it should use the
> server name in all places.  What do you think?

I agree.

> (Of course, the sole exception is gnus-secondary-select-methods if set
> by the user, or the list of servers as per the server buffer.)

IMHO there should only be one list of servers, and it should be
customized, and the server buffer should be a customized viewer/editor
of that variable.  It should be aware of common server variables too
(SSL, Kerberos, etc).

Adding/removing/experimenting with servers is a hassle with Gnus. This
would be a step towards making this is easier.

Re: nnimap/nnagent troubles

[Christoph Rohland]

Simon Josefsson <simon@josefsson.org> writes:

> Christoph Rohland <cr@sap.com> writes:
> >    I tried to use ssl as connection type, but somehow my
> >    laptop did not use it despite the fact that I did set the
> >    parameter in gnus-secondary-select-methods. 
> 
> Ah yes, the curse of changing select method without removing
> references to the old server.

Yes, I did change nnimap from primary select method to secondary
some time before...

> Since Gnus store the full server in various places (in every group
> info, in agent etc) you need to unsubscribe groups, unregister the
> server from the agent and THEN change server method in your .gnus. If
> this isn't done, there will be inconsistent server specifications in
> various parts of Gnus causing all sorts of strange problems.

But I think here lies the culprit. gnus stores many information
redundant and also mixes very different kinds of them up.

It should really follow its own data structure for configuration by
having one point to store the server information and another for group
information which only should reference the server by name. (see the
agent issue) and it really should not mix the more transient status
information (~.newsrc) with the configuration.

Actually I would think of something like:

1) .newsrc(.eld) stores status information for the articles.
2) We have a server config file which stores all the server info. The
   agent should also use this.
3) We have group config files: To which server does it belong (and
   only one reference). To which agent category does it belong? We
   could extend this to a directory and directly store the relevant
   files like overview and cache/agent files here. (BTW cache and
   agent [c|sh]ould be one thing.) Probably the score file could be
   here also.

        Christoph

Re: nnimap/nnagent troubles

[Kai Großjohann]

On 03 Sep 2000, Simon Josefsson wrote:

> Since Gnus store the full server in various places (in every group
> info, in agent etc)

I think Gnus should not store the full server; it should use the
server name in all places.  What do you think?

(Of course, the sole exception is gnus-secondary-select-methods if set
by the user, or the list of servers as per the server buffer.)

kai
-- 
I like BOTH kinds of music.

Re: nnimap/nnagent troubles

[Simon Josefsson]

Christoph Rohland <cr@sap.com> writes:

> Gnus should definitely give more output on error conditions! If the
> network connection fails, there is no way (known to me) to get the
> actual error (like "connection to <host>:<port> via {tcp|openssl}
> failed with error <errno>, <strerror>". So if something goes wrong the
> user is lost in the dark.

I agree, I often find myself debugging things to find the cause of an
error, when a error message should be sufficient.

>    a) why does the agent store all the server parameters in
>       agent/lib/servers? So any change to server parameters invalidates
>       the agent setup. The server name should be sufficient.

Good idea, I've added it to the todo-list.

>    I tried to use ssl as connection type, but somehow my
>    laptop did not use it despite the fact that I did set the
>    parameter in gnus-secondary-select-methods. 

Ah yes, the curse of changing select method without removing
references to the old server.

Since Gnus store the full server in various places (in every group
info, in agent etc) you need to unsubscribe groups, unregister the
server from the agent and THEN change server method in your .gnus. If
this isn't done, there will be inconsistent server specifications in
various parts of Gnus causing all sorts of strange problems.

nnimap/nnagent troubles

[Christoph Rohland]

Hi folks,

after fiddling one whole day with my gnus setup on my laptop I have to
get some words out.

Gnus should definitely give more output on error conditions! If the
network connection fails, there is no way (known to me) to get the
actual error (like "connection to <host>:<port> via {tcp|openssl}
failed with error <errno>, <strerror>". So if something goes wrong the
user is lost in the dark.

Now to the more specific errors all on :
Gnus v5.8.7
XEmacs 21.1 (patch 8) "Bryce Canyon" [Lucid] (i386-redhat-linux, Mule)

1) agent: 
   a) why does the agent store all the server parameters in
      agent/lib/servers? So any change to server parameters invalidates
      the agent setup. The server name should be sufficient.
2) .newsrc.eld:
   I tried to use ssl as connection type, but somehow my
   laptop did not use it despite the fact that I did set the
   parameter in gnus-secondary-select-methods. 
   a) I discovered, that gnus had stored the nnimap-address as group
      parameters in all groups. Apparently preventing the use of the
      server setup (agent still used the server settings)
   b) After removing these Group parameters things became more wierd:
      Doing 'g' did lead to denied nnimap server, but doing 'J Y' did
      open a connection!?! (Took me some time to realize what
      happened. It looked first like random failures)
   c) I compared my .newsrc.eld with a working one and realized that
      the broken one had stored (nnimap "") instead of "nnimap:" in
      .newsrc.eld for every group. After replacing these everything
      works now again (and with ssl).

To find all this took me lots of dialups and shuffling of
configurations. Unfortunately this was not the first time I had to dig
deep into the internals of gnus. If something failes it is _very_ hard
to find the cause. That's the reason why I cannot recommend it to
other users. There are not a lot people who are willing to spend so
much time on their mail setup.

But still: As long as it works it is the best mailreader I know!

Greetings
                Christoph