Comments on TODO

Dirk Nimmich <[email protected]>
Newsgroups gmane.network.tin.devel
Message-ID <[email protected]>
Some comments on TODO entries:

|  a wrong usename in ~/.newsauth can't be corrected in the first
|  pass
|  [20050816 Urs Janssen <[email protected]>]
      
As you know I've been trying to fix this in auth.c.  In my local
copy I do have a "solution" (minus the USE_CURSES issue), but it
still suffers from the main problem:

When an authentication attempt is not successful, the server closes
the connection (which it shouldn't, according to the protocol, but
must be handled anyway because the server could also have sent a 400
error code) and tin does a reconnect. This leads to a recursion in
authenticate and is the reason why the username of the "first pass"
(which actually is the second pass if you have a .newsauth file)
doesn't seem to make it to the server -- it is sent again in a third
pass after the recursion ends, so you have authenticated twice. If
the username/password pair from your first imput was wrong in this
pass, you would be asked again even if you were successful earlier
with the pair entered the second time.

The final solution would be to prevent the recursion. This means
that we can't handle authentication failures directly in auth.c (but
in the functions that use authenticate()) and have to make sure that
we don't reconnect if we just tried to authenticate.


|  unexpected multiline responses confuse tin, e.g.:
|  | 240 Article posted =?ISO-8859-1?Q?=3C=3D=3Fiso=2D8859=2D1=3Fq=3F=3F=3D87r7k8na?=
|  |   =?ISO-8859-1?Q?vt=2Efsf=40urs=2Did=2Etest=2Eka=2Enu=3E?=
|  (the servers response should be a single line (INN 2.2))
|  [20050207 Urs Janssen <[email protected]>]

This may be fixed by draining (read.c:drain_buffer()) the NNTP
stream, but only when pipelining is not used/allowed. Not tested.


|  Changes to int/bool tinrc variables in the Option Menu don't propagate
|  back to the attributes, not even groups with global attributes.
|  This is because the Option-Menu in {group,page}.c doesn't reread the
|  attributes, whereas select.c does. Fix the problem properly in config.c by
|  flashing changes to all affected groups and remove the reread of the
|  attributes file from select.c

Could be done by putting the reread of attributes to config.c. I
remember not doing this because of side effects when you are in a
group. Some keys change an attribute value so when you reread the
attributes file and the default value was changed the user may get
confused (and consider this a bug).

The problem should mostly go away when the dependencies between
tinrc and attributes are resolved and attribute values can be
changed and written like tinrc values.


|  - -cZ has an unclear return value (shall we return 0 or 2 if there
|    was unread news before -c marked it as read?)

Well, after -c there are no unread articles, and -Z only indicates
an execution mode, so it should be 0. I think this is consistent
with the man file.


|  'K' is still a bit inconsistent:
|  - in the group and thread menu it marks current item read & jumps to the
|    next unread item.
|  - in the article pager (page.c) it marks the rest of the current thread
|    read and jumps to the next unread article. should we let 'K' behave
|    like <TAB> in the pager?

and

|  tin uses the first sig-isolator as recent one, USEFOR says it should
|  use the last. There is no consensus that tin should follow this USEFOR
|  requirement.
      
Unless these questions can be answered now we should move them from
the "Bugs" to the "Not yet classified" section.

Regarding the signature delimiter it should be referred to the
USEAGE draft. For the record: I think it is useful to use the last
one.


|  add a _-_ to the local part of the MSGID on a subject-change

Is this still a feature we want to implement? AFAIK only gnus makes
use of it, and it is only documented in son-of-1036. No current
draft (USEFOR (in IETF last call procedure), USEPRO, USEAGE drafts)
mentions it.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.