World: r3wp

I was thinking of using net-log as a way to hook into the low level 
activity of the protocol so that I can patch it as needed when interacting 
with a GUI ... eg, for progress meters

Ok, good... then I'll start with IMAP... since it's more recent.

One thing that is not clear to me is that if you write to the port 

eg. write imap-port [ dialect stuff ]

and then 
wait imap-port


it can return immediately ... and you don't get anything unless you 
put in a timeout

eg. wait [ imap-port timeout ]

Ok, let me upload the latest version ....

Isn't that dependent on what you return from awake?

in wrote there is a 'read port .... but i don't get anyting back 
without the timeout

uploaded 0.0.3 

can login, select a mailbox, get length? and pick

It's at the bottom of the page as a file attachment

BTW, nice use of Deki wiki.

It looks pretty but is slower than docbase :)

and there's no REBOL formatting .. so I use ruby or whatever ...

Runs really fast here. Where's the server?

I think EC2

It was a free hosting offer I picked up a couple of years ago ...

That is Mindtouch were offering free wikis to people limited to 200Mb 
I think

Of course what I really like about it is that there is a REST based 
API that I can use with REBOL.

Carl - guys found out, that we have just one shared buffer - why? 
You have to read everything out during read phase, or you can get 
corrupted data ....

pekr, what protocols are full duplex?

none ... but wasn't it you, after all, who just wondered, why the 
in-out buffer is shared?

No .. I just pointed it out.

And wondering if that imposes a lot of GC ...

It's one of those things that's in the "balance".

It turns out, I think you can allocate separate buffers, but you 
must know how to do it... and I've not tried it yet, so have not 
mentioned it either.

But, I did give full duplex consideration during implementation. 
 I think more modern IM systems benefit from it.

Also, it turns out that one must be careful when estimating GC overhead. 
Sometimes it is more efficient, becuase otherwise you must add extra 
code to manage memory usage... that is constantly being run. You 
know what I mean?

It wouldn't be a big change to the schemes if that gets implemented 
right ?

Right. No change to schemes.

lunch time, bbl

I think in my ftp scheme I access port/data directly so I can stream 
to the file system .. so it would require a tiny change if there 
were two sep buffers

Graham, instead of
    write imap-port [ dialect stuff ]
    wait [ imap-port timeout ]
could you try:
    write imap-port [ dialect stuff ]
    read imap-port
    wait imap-port
I think that should work.

Graham, before looking at your new schemes, I decided to review some 
of DocBase. But... I must say that I have a difficult time finding 
things there... I'm not sure if the user who was reorganizing it 
got a chance to finish the updates.

On http://www.rebol.net/wiki/Table_Of_Contents-- I've added some 
links to ports and schemes. Did I miss any?

Hard to say ...

If I find anymore I'll update the wiki 
Andreas, going to try that now.

You did have an example somewhere of doing a large file transfer 
between client/server

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

http://www.rebol.net/wiki/Ports:_Synchronous_and_Asynchronous_Operations
may also make sense to be linked up

Ports:_Synchronous_and_Asynchronous_Operations -- that is

A: do you have a wiki account?

Not yet

OK, created an account. I'll simple add those links myself, then

I tossed a few up just now. Go ahead and add or edit as needed.

looks like we side tracked into a docbase update ...

Already debugging the IMAP thingie

Not a sidetrack. See my note. This is an opportunity to check the 
docs against the code.

Ok, fixed the IMAP proto so that no timeout is needed anymore. Stumbled 
over what seems to be a bug in R3's USE, though:

>> foo: func [] [use [] [return 42] 0]
>> foo
== 0

Looks like this bug is what was causing me grief ...

Reported as bug#1436

Updated to 0.0.4 
working http://rebol.wik.is/Rebol3/Schemes/Imap4