World: r3wp

where the action occurs pertains to how the code is structured

ok, tcp port is good too .. I've always found the use of subport 
in r2 confusing ..

true

i should've broken with that habit :)

so, to stop with this pollution of huge urls: http://bit.ly/7cflf4

and the flow up to "buffer USER" will be pretty much the same for 
each protocol that sends and initial welcome message

where the server sends an initial welcome message, that is

if the client is expected to send a request before receiving anything 
from the server, things will look different

the other design issue is wether the protocol should be sync or async 
for the user (i.e. the "script")

sync behaviour is depicted in this picture. basically each READ will 
WAIT on the tcp port until the response has fully arrived

if one would like to expose an async scheme, instead of the first 
WAIT, control will return to the script

ah, not really!

you'd return TRUE from the CONNECT event handler, and returns through 
all back to the script

i think the lookup should most of the time wrapped silently, and 
not asyncly exposed to a scheme's user, even if the scheme is supposed 
to be async

your pop scheme is sync ..

yep

but i'd love to be provide an async mode as well

problem is: we can't truly do that yet

but that would be _my_ answer to your recent read/as concerns

I'm forcing sync by waiting until all the data has arrived

so do i

foo: open ftp://.....

foo/awake: func [event] [ ... handle events like 'file-start, 'file-chunk, 
'file-end ..]
write foo [RETR %avatar.avi]

so what do we need ?  a thread that controls the awake handler?

you see where i'm going with the above pseudocode?

and write returns immediately?

precisely

So, does mine .. . but I have to kick it off with a wait

wait foo

that's what i'd want

and now you're stuck ... waiting ...

currently we have to do wait foo/..../subport, as far as i can tell

then, as far as i currently understand it, read foo should work

that's what my read does, it does a wait on the tcp port

you'll have to "block" somewhere

the transfer won't happen in zero time

to indicate when it's fine to block: WAIT

but well, i don't think we can get that to work, at the moment

i'll have to experiment a bit more

so I can't return immediately from my read ... and let it download 
?

somewhere you'll need something that blocks, yes

if you want to download while in the console, that could be a console 
background worker thread

if you want to download within a GUI app, that could be the GUI's 
main event loop

well, generally inside a gui .. so that's okay I guess.

something that blocks: an event loop

i.e. something that checks all ports registered via read for incoming 
events, and dispatches events accordingly

so we add a gui event to the thing .. and we work inside of that

fine for gui's, yes

shouldn't be bound to guis

R3 actually needs an event loop to work anyway

it's there on win32, not there on linux (yet)