pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] RFC versus sever versus client


From: Rhialto
Subject: Re: [Pan-users] RFC versus sever versus client
Date: Sun, 13 Nov 2016 13:07:14 +0100
User-agent: Mutt/1.7.0 (2016-08-17)

On Sat 12 Nov 2016 at 16:58:32 +0100, Per Hedeland wrote:
> ...and in case there is interest in it, the attached patch for Pan does
> just that - I've tested it against what I believe is the server the OP
> is referring to, in any case it is one that does return 500 for MODE
> READER.

How likely is it that more commands in the future will require similar
treatment? As it is for one command now, this very specific hack works,
but it won't be a great solution for the general case (if needed).

Now personally I'm not a fan of abstracting things when it is not yet
needed but when it is complicated, so I'd propose that if a more general
solution turns out to be indeed complicated and hard to follow, that it
isn't done (yet).

(And now that I am looking at the code in nntp.cc, I see some complexity
that I don't see the need for (yet?). In functions like
list_newsgroups(), a command is queued, and then the first command from
the queue is sent to the server. Who guarantees that the queue was empty
before, and that this is the just-queued command? Yes, the _listener
member is set with just this assumption. Either the assumption should be
checked, or better yet, if possible, the whole queue should be removed
and replaced with a single ""current command". That also makes it simple
to add a flag for "ignore any errors on this command".)

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl    -- are condemned to reinvent it. Poorly.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]