World: r3wp

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 ?

both ...

where does all this tcp syn syn+ack and ack occur ?  Is it automatically 
done in the tcp device?

I think we should have a common way of tracing network functions 
.. like trace/net on

the R2 protocols use net-log so how about we do something similar?

we could rename this group to !REBOL3 protocols ... we have REBOL3 
back now ...

Shame ... I quite like this group as is, ,but probably !REBOL3 network 
schemes is a better title.

Here's a reference for ftp client implementors http://cr.yp.to/ftp.html

Note that Bernstein recommends only using Passive mode as Active 
FTP is a security risk.

I can't even remember ever having to use active FTP, because passive 
didn't work. It's usually always passive that you have to use.

Certainly will make it easier to only support passive as then we 
don't have to open a listen port for an incoming server connection

Andreas, you have this 


		open?: funct [port [port!]] [
			open? port/state/subport
		]
recursive function

I guess it croaks after the 2nd call

This isn't of much use yet .. http://rebol.wik.is/Rebol3/Schemes/Ftp