World: r3wp

`write mbox ["RETR" 1]` should work

shouldn't state always be set to 'retr after all write commands?

ie. you always want to get the response until you hit the "."

that's only for multiline commands

or a "+OK" or a "-ERR"

STAT, DELE, RSET only have one-line responses

NOOP

QUIT

(for example, yes)

actually, WRITE exposes the low-level interface here

for RETR, PICK would be the high-level interface

cause I get nothing back aftre

write mbox [ "RETR" 1 ]

etc

read mbox

and you'll get whatever the command handler deems to be the right 
result to pass along

ahh....

write mboxc [ "TOP" 1 10 ]
hangs :)

after the read ...

obviously, as there's no top handling yet :)

write mbox [ "TOP" 1 10 ]
read mbox

not the way it's suposed to work?

I see the top 10 lines and a "."

yes, in the debug output :)

open, length?, pick, close -- that's the currently supported interface

ok :)

open? is also supported

Just needs a little error handling ...

yep

schemes aren't so hard :)

and an async mode, of course :)

nope, they are rather nice :)

actually, if you want TOP to work, you can use the internal write/read 
as well

ah, no, you can't. my mistake :)

well, I was just thinking that it should work as I tried it :)

you send the command to the port and retrieve either a multi or single 
line response

write is not really intended for the user

i think that all common commands should be supported by nice higher 
level wrappers

Sure ... but then a new command comes along ...

say I want to UIDL ?

exactly, that's when you'd use write/read directly

+OK, what's next ?   Ftp :)

hehe, i could abuse write/lines as indicator that a multiline response 
should be parsed

Normally you set a state so that your machine knows what to expect 
next

unfortunately i can't know for all possible commands in advance wether 
they result in single- or multi-line responses

at present there's a finite set of commands :)

well, anyway, have to run, for now

there's also the issue of returning the data to the client issuing 
the command.

Ok, just streaming to myself.

If you're retrieving a 20mb file via email, you really want to send 
each part back to the client as you get it and not just store it 
in locals as the original r2 pop scheme does.

I found this ftp sequence diagram which might help understand what 
happens http://www.eventhelix.com/Realtimemantra/Networking/FTP.pdf

Does r2 ftp support passive or active ftp ?