Re: Comments on TODO

Urs Janßen wrote:
> In <[email protected]>, Dirk Nimmich wrote:
> > 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.
> 
> IMHO we can repormpt the user for auth data in an endless loop as
> long as we give him the possibillity to ESCape from the loop.

Yes, maybe we can (I'm not really sure if we can, given the current
code and the two step protocol, where the second step can be omitted
on the server's choice). But this is independent from the problem
described above.

> we just shoukld make sure that we do not reprompt him if he
> allready gave correct auth data.

Yeah, "just" ... this seems to lead to a major rewrite of the
authentication, reconnecting and nntp open routines.


> in the long term we need an attributes 'M'enu

Yes.

> but that's a bit tricky as attributes can be scoped and the order
> in the file does matter as later settings may overried earlyier
> ones ...

I don't see a problem here. Could be done similar to the selection
level with the scopes being the "groups" that can be moved around.


> > |  - -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.
> 
> but then -cZ isn't very usefull at all

So what? :-) -c explicitly says there are no unread news anymore.
And would you like tin to start interactively if you used -cz?
That's the same situation. (BTW: This currently dumps core in
global:set_first_screen_item(), line 73, because NOTESLINES is
uninitialized/0.) Additionally, -xw or -xo or -cX for example don't
make sense as well, and I don't see why this should be a problem.

If you need to know if there are unread news but want to mark them
read you can run tin twice. Or you use -cvZ and parse the output.

If you still think -cZ should be "useful" then I suggest you remove
the question in this TODO item and replace it with a task ...


> > |  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
> 
> I don't think so.

Ok, then it should be removed from TODO. :-)