World: r3wp

it's not much different in Carl's version.

set-face doesn't update until the network activity has ceased

Maybe I did something wrong ... perhaps someone else can try it

how are you doing it? the set-face has to be called from somewhere 
within the networking code. alternatively something is synced which 
shouldn't be synced.

http://rebol.wik.is/Rebol3/R3_GUI/Sendfax.r

I update the GUI in the awake handler

inside prot-fax-r?

Yes ... as I redefine net-log in the gui to do the updating, and 
net-log is used inside pro-fax.r

ok, I see it

what good does the last line do?

what last line?

set-face/field a1 tail get-face a1 'locate 
txt

sets the text cursor ?

been a while since I wrote that code .. hard to remember now!

I wonder if it's there to force the text to scroll to that point 
...

The issue in updating an area is to show the new text ... which may 
be out of sight unless you somehow force the area to scroll down 
to the new text

Gabriele, thanks for the clarification. I'll give it a try over the 
weekend.

On first examination, executing the following code seems like an 
unexpected error. Doing

port: make port! http://www.rebol.com
port/awake: funct [event] [
    port: event/port
    switch/default event/type [
        read    [prin "read:"    copy  port]
        lookup  [prin "lookup:"  query port open port]
        wrote   [prin "wrote:" ]
        connect [prin "connect:" read  port]
        ready   [prin "ready:"   close port]
        custom  [prin "custom:"]
        done    [prin "done:"  ]     
        close   [prin "close:" ]
        error   [prin "error:" ]
        custom  [prin "custom:"]
    ][
        true
    ]
]
open port
wait port

gives

connect:wrote:read:custom:** Script error: res: needs a value

** Where: either case check-data either switch check-response switch 
applier wake-up loop applier wait catch either applier do vv
** Near: either headers/content-length <= length? port/data [
    sta...

in prot-http.r, in http-awake function, there is a switch statement

res: switch state/state


try adding a switch/default instead

and use 'none for the default to see what happens

and probe state/state to see what value might be causing this error

HTTP-AWAKE is the event handler for the underlying TCP port, from 
my understanding the awake handler for the HTTP scheme should be 
way simpler.

I'm getting better results with

port: make port! http://www.rebol.com
port/awake: funct [event] [
    port: event/port
    prin join event/type ":"
    
    switch/default event/type [
        connect [read  event/port false]
        ready   [read  event/port false]
        read    [query event/port false]
        custom  [copy  event/port false]
        done    [true]
        close   [true]
    ][
        false
    ]
]
open port
wait port

That gives the following output:

connect:wrote:read:read:custom:done:

But at the 'DONE EVENT/TYPE it then hangs. By returning TRUE there 
the AWAKE handler normally should awake the port, making the WAIT 
return.

this is true for a tcp port, but this is a http port, and Gabriele 
has two handlers there, one of which is creating custom events.

Since your code is handling custom events, I presume that you're 
handling the events generated by the main awake handler ...

Ok, this is confusing, and it doesn't help that I have absolutely 
no expertise in that networking stuff. It doesn't help, I'll have 
to dive in anyway. So excuse me when occasionally I come here panting 
for some air before drowning ;-)

It seems to work fine, reading the page like it should:

port: make port! http://www.rebol.com
port/awake: funct [event] [
    prin join event/type ":"
    
    switch/default event/type [
        connect [read event/port false]
        ready   [read event/port false]

        read    [probe length? event/port probe query event/port false]
        custom  [probe to string! copy event/port false]
        done    [true]
        close   [true]
    ][
        false
    ]
]
open port
wait port

It just doesn't return when it's DONE. Even though the last state 
is that DONE state and the awake handler returns TRUE. Reading further 
...

The CUSTOM event/type is generated by the lower level TCP awake handler, 
with event/code set to zero when transfer is completed. So, TCP-awake 
calls HTTP-awake with an event with event/code:0 and event/type: 
'custom

And it makes no difference if at that point I return TRUE or FALSE, 
the wait hangs

To me, it almost looks like things aren't working "as advertised", 
which may be because docs and code aren't properly sync'ed.

Graham: I suspect that your problem is simply that you have to wait 
on all the ports (including events), not just the network port. Don't 
forget that R2 has a "hidden" list of extra ports to wait for (system/ports/wait-list), 
while R3 does not AFAIK

Yes, that's what I'm after, Gabriele. Opening a network port and 
then waiting for network, time, or gui events.

Christian: does the example on the wiki work? If not, then something 
has been changed since then, and I can't help much without studying 
everything back again. If so, then maybe we can figure out why your 
version does not work.

studying your own code ?  :)

ie. this one:

   port: make port! http://www.rebol.com/
   port/awake: func [event] [
       switch event/type [
           connect [read event/port]
           done [print copy event/port return true]
       ]
       false
   ]
   open port
   wait port

Graham: mostly, the changes in R3, and trying to figure out how it 
works now. It's not like there are docs with enough details...

Gabriele, that's the main point of confusion to me, that even that 
example fails. I.e.. hangs when DONE, in the same way as my attempts 
on this.

Ok, so it's not your fault. R3 has changed and the HTTP scheme does 
not work correctly anymore.

Good to know. I like the line "It's not like there are docs with 
enough details..."

I think I read somewhere Brian saying that http had to be modified 
as chunked encoding didn't work or something like that

But the source was modified and not the rlp

IIRC http was degraded to 1.0 from 1.1 due a problem Graham describes 
...

Isn't there a source code revision history somewhere??