World: r3wp

in that case the docs need to be fixed!

yes probably

I just ran the code .. the lookup does occur in the client

well well, let me try it again

so, I think it is what I said .. the lookup event always happens 
.. and it is triggered by the obtaining of the ip address.  It is 
the lookup itself that need not occur.

and that happens in the tcp device

ok i see what is the problem.

at the start, replace: 
>> client: open tcp://127.0.0.1:8080
by
>> client: open [scheme: 'tcp host: 127.0.0.1 port-id: 8080]


You will see that the lookup event is not fired, then i'll explain 
why

or maybe you'll figure it

true .. not fired

give up ...

In my own code I see two lookup events one after the other ...

so if I put an 'open in the lookup event, I open the port twice

brb

Does parse skip spaces automatically in r3 ?

parse "OK OK" [ "OK" "OK" ] is false in R3

seems not ...

parse "a b c" [ "a" "b" "c" ] => false

I think that was changed from R2

Looks like it ... no mention so far that I can see of this new behaviour

Looks like the learning curve is going to be steeper than I thought

It was discussed maybe half a year ago. Don't remember where; there 
are so many possible places

Or probably more recently during the parse project

Ok, I wasn't paying attention ...

what's the equivalent of set-net ?

ie. where is the smtp mail server information stored and where is 
the email stored?

There's no SMTP, so no need for set-net yet

there's no system user object

Ok, this is pretty buggy and doesn't seem to send a well formed email 
... not sure why

http://rebol.wik.is/Rebol3/Schemes/Smtp

Anyway I've posted it for discussion, and to allow the rebol optimizer 
have a look ....

There are quite a few issues with it.

As soon as I connect the server sends me a "220" I can only get that 
by sending the EHLO.
Which triggers me to send another EHLO :(

I didn't bother with the authentication as that can be pulled out 
of prot-esmtp that Gabriele wrote.

thanks for posting, graham

i think you can fix the duplicate EHLO by doing a simple "read client" 
instead of the write

that should re-schedule the port, so that it next awakes with a read 
event

it doesn't need it, cause the wrote event always do it

yeah, but there's nothing to write for the client at this point

you mean after it's connected, the client  should only waiting for 
data ?

exactly

i see

got it working .. need to enline the header

what do I need to change??

but is that really a burden to send by default an EHLO ?

#                 ; need to write to the client to trigger flow of 
data  

#                 write client to-binary net-log/C rejoin ["EHLO 
" ehlo-msg CRLF]  
#                 ; now ready for the next state  
#                 client/spec/state: 'AUTH

change this to:

read client

give it a go ...

seems that is doesn't bother the server :)

client/spec/state: 'INIT

no, but it bothers graham's state machine :)