World: r3wp

in the above... would == could == should  ;-)

Also for things like download meters ...

There might be a /with option for READ, which supports additional 
options in an options block, but there won't be any other options 
outside of that block. READ is a low-level function, and won't have 
more refinements.

Brian: ok... let's make it easy... i just copied it here: http://www.rebol.it/giesse/wetan-test.r
and http://www.rebol.it/giesse/wetan-template.html- they just need 
to be in the same dir.

bsd is fine for the license, or mit, one day i'll release it properly 
and attach a license. :P

I've been reading some more of the docs .. and it says that the lookup 
phase in the awake handler is called when the name is resolved with 
a dns lookup .. but that phase is not used when the url uses an ip 
address.  But then I see some demo code using IP addresses ( the 
ping pong server ) where the open port is in the lookup event ...

Did you test it ? 

Being in the source code example doesn't mean that the lookup event 
is fired.

http://www.rebol.net/wiki/TCP_Port_Open_Issue


perhaps it means that the lookup event is passed to the handler once 
it obtains the ip address

that's probably it ...

if the ip address is passed initially, then no lookup is sent to 
the tcp device

exactly

the weird thing is that you need to perform 2 OPEN when the ip need 
a translation.
A little disturbing...

Is that done by you or automatically ?

must be done by you.

see in the example:
lookup [
	....
	open port
]

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