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 
>
>  
>
>  

  

 

Reply via email to