OpenEuphoria

2. re: Problems with webutils

• Posted by gertie at ad-tek.net Aug 02, 2001
• 412 views

On 2 Aug 2001, at 16:05, Ted Fines wrote:

> > 
> Kat,
> 
> Thanks for the reply & code snippet.  I think I'm missing something basic 
> with this.
> 1) In your code, you quit when you receive a '13'.  Does '13' signify end 
> of transmission?

POP3 lines are ended with at least one one CRLF. 

> 2) Why do you drop the '10' character--won't that elminate returns?

I wanted the function to return the data, and didn't need the line terminator,
whatever it
is. It does return the CRLFCRLF terminator for large *blocks* of data, like an
email
which can contain the CRLF in the text. I haven't looked at it in a while, but i
should
add a switch for not deleting those chars within the blocks, if i use it for
anything but
checking for the presence of email..
 
> For example, the IMAP command
> A FIND ALL.MAILBOXES "*"
> might return quite a few lines (however many mailboxes the user has), such 
> as:
> * MAILBOX INBOX
> * MAILBOX Accounts
> * MAILBOX ArcServe
> * MAILBOX Cisco
> * MAILBOX Corporate Time
> * MAILBOX DNS_DHCP
> * MAILBOX Euphoria
> * MAILBOX Linux
> * MAILBOX Novell
> * MAILBOX PMDF
> * MAILBOX Robots
> * MAILBOX Verisign
> * MAILBOX WASTEBASKET
> * MAILBOX deadletter
> a OK FIND ALL.MAILBOXES completed
> 
> Won't it be bad if I delete out all of the \n characters?  Isn't a '13' and 
> a \n sent at the end of every line?

In IMAP, as i understand it, you *could* have a 10, or a 13, or a 10,13 or a
13,10. Like
i said, i couldn't get to imap.org, but there should be a function to recognise
what the
terminator will be, and i expect you'll want to toss out the terminator to parse
the
command parameters in the lines. So grabbing one line at a time from the winsock
cache, processing it, and returning for the next line is just easier than
writing your own
cache, reading gobs into your program, hoping it doesn't hang with a net
interruption,
making the user wait instead of scrolling the window with data they can read
while you
process the incoming, etc etc. FINDALL will return data untill it says it is
done, with an
OK, and all the intermediate lines are the mailbox names, separated by the
terminator.
you code knows it is in FINDALL block of code and will know how to parse the
data
stream up to that OK, cause that's the way you wrote it. It's the same way with
all the
commands. When you get back  "* MAILBOX DNS_DHCP\n\r", you don't store the 
name of the box as that do you? No, you strip off the "\n" and "\r". Just as
easy to do
it as you have it in your paws in the read() function, simply drop it on the
floor and
return(), than to do it later. But either way is ok.

> Or more simply, how do I know how much data came back, and when I can stop 
> looping for it?

In my code, i ask winsock if there is any data waiting (i ask tcp4u actually),
and if
there is data, there is at least one byte, so i ask for it, and then ask if
there is another
one. That way i am not asking for data that wasn't sent, thereby hanging the
program.
If there is a net connection, and you lose the eol terminator, but get another
command
string, that's how you can tell if you missed a eol, there can be only one
command per
line. The reason i do not loop based on recieving a command tho is simple, what
if
there is a word in the command parms that is a command word in *another syntax*?
And if you recieve such a word, and loop till you get the params you expect, and
the
server isn't rfc compliant, or the specs change, you must rewrite code. My isps
are not
POP3 compliant, no telling what i will get after a "+OK", for instance, so i
haveto know
what i am expecting, regardless of what the english phrases say was sent. One
isp
sends email totals for one command, and the other doesn't. One kept "upgrading"
to a
server that would not allow header retrieval. The other one periodically aborts 
everything and tells me the rest of the world is gone. It pays to cover your
posterior in
these things.
 
Kat