[REBOL] Re: pop problems
From: gscottjones:mchsi at: 18-Oct-2002 9:26
Hi, Graham and Brett,
> On Fri, 18 Oct 2002 14:56:25 +1000
> "Brett Handley" wrote:
> >I've asked Graham to check out my theory. In the
> > meantime this I what I reckon - the POP scheme
> > can't handle a line length greater than 4093. Here's
> >a little view program for those interested to test the
> >idea:
>
From: "Graham Chiu"
> Interestingly although this does not reproduce the problem
> for me, it seems Brett does have the same problem in that
> read-til-dot gets stuck in a loop returning none.
>
> The length of the string may be OS dependent. He is using
> NT 4, and I'm using XP.
Brett's mutli-x (4094 to be exact :-) -rated email did trip up REBOL on
Win98se for me.
When I looked at the offending email in your (Graham's) link folder, I am
wondering if Brett not be on the right trail, in that the offending email
uses HTML with no line breaks.
When I experimented, I discovered that it appears to be REBOL's line buffer
cannot "absorb" enough characters, at least for NT and Win98. Given the
inherent line-oriented nature of POP servers, it is understandable "why" RT
used open/lines on the port. But "inconsiderate" email client's that don't
offer line breaks seem to break REBOL with its current line buffer.
So, I rewrote the pop scheme to switch from line mode to character mode once
it begins to read messages. After some fiddling (forgot that newline is not
necessarily equivalent to "^M^/" ... whoops there goes an hour of time:-), I
got the function to work, so I reintegrated it as the central "read-til-dot"
function, and so far it seems to work. It is less than elegant, because I
needed to maintain the carriage-return and line-feeds for the port
processing logic, but wanted to return the buffer back to the equivalent
REBOL newline (hence the replace/all call before the return).
If indeed the base problem turns out to be the line buffer, it would be more
elegant to improve the native functionality and leave the scheme alone
(which was neat in its original form). But my function replacement seems to
be more robust for now.
Graham, if you decide to try it and it "fixes" the hanging port problem, I
would like to report this to feedback, of course.
Hope this helps. And thanks to Brett for detecting at least one problem that
breaks the pop scheme!!
--Scott Jones
read-til-dot: func [port buf][
set-modes port [lines: false]
line: system/words/copy ""
while [line <> ".^M^/"][
line: system/words/copy ""
while [not find line "^M^/"][
a: system/words/pick port/sub-port 1
if integer? a [
append line to-char a
]
]
insert tail buf line
]
set-modes port [lines: true]
replace/all buf "^M^/" newline
buf
]