World: r3wp

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

Can login ... and switch to passive mode ...

It's not syncing correctly ... must be my state machine is confused

And wonder why I need to issue multiple reads to get all the data 
....

graham, afaic open? should work as it is. as the actor functions 
are contained within a block, the bounding is left to make-scheme. 
and make-scheme leaves the inner open? bound to the system version

actually, that's a rather nice property of the whole actors-as-a-block 
model, that each call to read/write/etc within an actor function 
calls the system version of the word, not the actor version

on the other, things look a bit confusing, at first sight. open? 
being a prime example of this

the bounding = binding

Just tidied up my ftp skeleton ... why is that a wrote doesn't trigger 
the next event ?

hm, no idea, looks sane to me

I was afraid of that ..

well, I can fix it by putting a wait 1 in the wrote event

sounds like an awful hack :)

so you're struck after write ftp ["PASV"] ?

not stuck ... just at console