And to note, other IMAP4rev1 servers I connect to issue the whole response
before sending the headers (or message, etc)
so the response should be
>
>
>command: A007 UID FETCH 375286, 145418 (RFC822.SIZE RFC822.HEADER
>FLAGS)
>
>response: * 5 FETCH (UID 375286 RFC822.SIZE 3223 FLAGS (\Answered
>\Seen) RFC822.HEADER {331} <header here>
>
>
> Wed Apr 05 2017 12:47:55 PM EDT from bennabiy @ Uncensored Subject: Re:
>Status?
>
>
>
>Here is a pastebin of a session with highlighting indicating the places
>where trouble is caused...
>
>https://pastebin.mozilla.org/9018063
>
>Notice that the return from citserver on lines 41 and 42 should all be on
>one line with no \r \n between them. Some clients are erroring because they
>never see the final ) of line 50 as the completion of the fetch.
>> Wed Apr 05 2017 12:39:01 PM EDT from IGnatius T Foobar @ Uncensored
>>Subject: Re: Status?
>>
>>
>>That's a little confusing but I'll look at it later and try to pick it
>>apart.
>>The ideal situation would be if you could give me the full RFC822 source of
>>a message that produces the problem (redacted of private information if
>>necessary) along with the IMAP command you are sending. Then if we can
>>determine the difference between the expected result and the actual result,
>>that should be enough to produce a fix.
>>
>>And now for a public service announcement to my fellow Citadel developers.
>>
>>I've just finished overhauling all of the modules which perform outbound
>>polling over the network. Originally we had what I will call Gen 1 pollers,
>>which implemented all of the protocol handlers in-tree. This was less than
>>ideal. Then we moved to Gen 2 pollers, which were comprised of a complex
>>matrix of asynchronous event-driven callbacks. The new pollers, which I am
>>calling Gen 3 pollers (with one exception, which I intend to correct) are
>>based on one single principle: "let libcurl do all the work."
>>
>>This may seem like a step backward because it returns to the
>>single-threaded model. And I want to say in advance to the developers who
>>worked on the asynchronous code: this is NOT a sleight towards you or to the
>>time spent writing the code.
>>I love you, you're a pepper, but the code is just too complex for me to
>>work with and maintain. By letting libcurl do all the work we reduced many
>>thousands of lines of code to just a few hundred, and removed two
>>dependencies from the build.
>>
>>Maybe it's just me who has trouble with the maze of callbacks. Just know
>>that the decision was not made lightly and I really really hope that the
>>developers whose code was removed will not be upset about it.
>>
>>Now for an exception to the rule. There is one poller, serv_networkclient.c
>>, that looks more like a Gen 1 poller than a Gen 3 poller. This is ugly and I
>>don't like it either, but since libcurl (understandably) doesn't have a
>>handler for our protocol, there wasn't a choice. Consider it temporary. In
>>the future I want to eliminate the idea of Citadel nodes polling each other
>>completely. We will either encapsulate room sharing packets inside email
>>messages and deliver them over SMTP, or even better, share rooms using NNTP
>>so the other node doesn't have to be a Citadel at all.
>>
>>Priorities now:
>>
>>1. Fix the issues bennabiy is indicating, one at a time and in order of
>>priority
>>2. Get back to building WebCit-NG
>>
>>
>>
>>
>
>
>
>
>
>
>
