World: r3wp

At present you have to supply an awake handler to the port ...

Just thinking we need a higher level interface to the network protocols 
to exploit their async nature.

For instance in Jquery .. you just chain functions ....

well, i guess I meant that its how I implemented the handler's switch/case. 
 it just forked off to callbacks.

Too low level I think and messy

Just want something like

read/cb http://www.rebol.com:call-back-function

what I mean is that, like face/feel, the handler is a low-level set 
of functions which should callback to application hooks based on 
events.

you could not... what events does the handler really manage?

could not what?

maybe, if it had an event name parameter.  a bit like the event action. 
 but the scheme handler still needs to exist, its the place where 
logical events are determined.

maybe supply a block .. where the first is the one you want used 
on success, and the other is an error handler

I'd rather it be just a function with error events instead.

but the problem with this is that with a single callback, it gets 
hard to tailor your stuff, cause everything has to happen in a single 
function.  I'd rather have named callbacks.

read/cb http://www.rebol.com'on-done :call-back-function

well, in that case we can use refinements

read/on-done http://www.rebol.com:callback

but each scheme will have its own  callbacks.  some schemes might 
support headers, others not... for example, in my http rss reader, 
I had a callback for the file size.  if it was too large, I'd refuse 
the rest of the read and close the port...

the other problem is that 'read doesn't support these refinements

yes, but if ports had a way to define callbacks, they would be passed 
on in some way by port using functions.


for example, a codec, would just be a callback which converts the 
stream or returns parameters to tell the port it needs more data 
before it can convert a chunk of input.

so read, would just have to pass it the codec function using /cb

read is going to have to get smarter and read the refinements in 
the 'read defined in the action block

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