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.