World: r3wp

client: open tcp://127.0.0.1:8080

this returns a port

structure

perhaps the second open should be done automaticly by the device 
after the handler processed the lookup event.
Would be less disturbing

and this then opens it

lookup [open event/port]

bit confusing because of the overloading of the 'open word

I think I remain confused

It's clearly explain in the link you pointed.

Note B

OPEN is called twice. It is moded. The mode is determined by the 
existence of the IP address. If the IP address is not known, the 
LOOKUP happens, otherwise the CONNECT happens. This also means that 
if you do an OPEN of a port where you provide the IP address, no 
lookup is done; you skip directly to CONNECT. If it is necessary 
to determine if the IP address is known (a rare situation), use QUERY 
-- which can be called at any time and is very fast.

the lookup event though always happens ... right?

no

only if a dns translation is requested

that's what I thought initially  but I think that's wrong

this is the ping client

client: open tcp://127.0.0.1:8080

client/awake: func [event] [
    ;probe event/type
    switch event/type [
        lookup [open event/port]
        connect [write event/port to-binary "ping!"]
        wrote [
            print "Client sent ping to server"
            read event/port
        ]
        read [
            print ["Server said:" to-string event/port/data]
            if (++ ping-count) > 50 [return true]
            clear event/port/data
            write event/port to-binary "ping!"
        ]
    ]
    false
]

I haven't tried it .. though to see if the lookup occurs

in this example, the lookup event is not fired. So it''s a bad example

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