World: r3wp

the blue liveness bars in the "port actor" might be slightly misleading

maybe i should use three separate actors instead (open, read, write)

i'll try that

heh ... should give us the link to the source of your diagram as 
well :)

Currently streaming a ftp download of the ubuntu server iso image 
... will see how that longs before I get an error.

http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgU2NyaXB0CgAHDFBvcgADDiJPcGVuIEFjdG9yIgALDlJlYWQABBVXcml0ZQArCAoAXwYtPgBnBjogTUFLRQBhBmFjdGl2YXRlAIEACG5vdGUgb3ZlcgCBEgcsUG9ydDogb3BlbiBQT1AzIHBvcnQARwkAFwZPUEVOClBvcnQtLT4AgSAKABEHAFgJAIE4DQCBRwotPlN1YnAAPgoAdwsiUG9ydCIsAIFxDSAgICBsb29rdXAABgVjb25uZWN0ABIFcmVhZCB3ZWxjb21lCmVuZCBub3RlAF0NAIFGBlJFQUQAgScIAII2CgARBwCBJQoAgk8MAIJdCgCBJAtXQUlUCgoAgTcHLQCBPwkgQXdha2U6IExPT0tVUCBFdmVuAIJcCyIAGQ0iADcIAC8GAIF8EGRlAB8ZAGwMZXJ2ZXIAhDEFOgCCCAkAg0MFcmlnaHQgb2YgIgAZCyI6IC4uLgoAKwsAgTIKADYKAIE-GUNPTk5FQ1QAgSA4AIJ4BQCBPBxsb29wIHJlc3BvbnNlIGltY29tcGxldGU_AIN2BQCCVRlSRUFEAIJlByAgICAAglcZADoLAIEGFiAgICAAgl0bZW5kAINZGwB7CwCDSycAgg4NVFVSTiB0cnVlAINeHACEZwoAhTEMZXhpdACFDAYAhSELAIcBDgBaBgCESA0AiDMMAIZbHjogYnVmZmVyIFVTRVIAhkITV1JJVEUAh30IAIhyCwASCACHfQoAiQwOAIkdCwCGTwwASQUABhYAg2UFKCoxKQAvDQCBSiEAigMOAIhDInNlbmQAgWcGAIhTCQCFDggAh3VoAIFgBgCISBpXUk9URQCDEIN5UEFTUwCFICgAJwUAhSImAJAbCgCIHRMAkHwMAJBEEC4uLgo&s=modern-blue

much improved version, schowing the actual activation lifetime

best consumed on a huge screen side-by-side with the code :)

I wonder if it might be better to call the subport the pop port instead 
?

it's the tcp port

port
 is the pop port

I know .. but that's where all the action is occurring.

if anything, i'd rather call the "port" pop3 port and the "subport" 
tcp port

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