I forgot to put the closing ) after the header... should go on a line by
itself
> Wed Apr 05 2017 05:12:19 PM EDT from bennabiy @ Uncensored Subject: Re:
>Status?
>
>
>
>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
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
