World: r3wp

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

There's some optimizing of parsing the input and checking for incomplete 
data returned on a read to be done.

I've updated it to v 0.0.5 which hopefully checks now for incomplete 
read data, and factors out some of the parsing

Back to separate buffers - just a note. I think that we eventually 
don't need them. But we should be carefull to user errors. Because 
with one shared buffer, if you write to it, before you read-out all 
incoming data, you just destroyed a data. And what if you don't need 
to act on the data yet? You will temporarily store it in some other 
storage (buffer) anyway. But I never wrote a scheme, so maybe this 
is just plain theory, and in fact having one buffer will not cause 
any problems to anyone ...

well, I think you normally read the data and then decide what to 
do with it.  So, you have saved it somewhere ...

Anyway I haven't had any issues so far .. and users unless they are 
writing schemes won't either.

I mean - what if data comes, but you don't want/need to react on 
it, but you need to write? You have to read-out the buffer first, 
before you write, no? This constant small chunk read/wirte could 
cause unnecessary overhead, or not?

Anyway - good to know, there is still some secret mode to reveal 
:-) So maybe one day Carl describes how to utilise two separate buffers 
:-)

I think it would be good if people actually tested the schemes!

OK, I will do few tests with my FTP Linux server, during the evening 
...

It would be good to get these all tested and written to a usable 
level while the code is still fresh, and while the spirit is willing 
...

Of course, Carl's code review may change all of that ...

With the latest code I got an error before the lookup event connecting 
to imap.aim.com and then it was ok.  Odd.

got an error event before the lookup event

Carl is going to review the code? What's going to be the outcome? 
Full rewrite? Or just some methodology/aproach suggestions?

I think that depends on the review :)

Right, that was the plan ..to get Carl to review schemes and advise 
on a "best" practice.

Carl is usually responsive when you give him something to look at.


if all he has to do is direct users into improving code, his intellect 
is much more usefull than if he is occupied hammering code out and 
sifting thru tedious RFCs.

I've got this in my network code ..

			;find/part msg join generator " OK" 8
			join generator " OK" = copy/part msg 8


and can't figure out why the first line does not work but the second 
does ....

Somewhere I came across a document that showed how 'open, 'read etc 
would search the schemes to invoke the correct actor.  Anyone know 
the link?

weird, I thought exactly the opposite. Why the second case is working 
?
Should be:
(join generator " OK") = copy/part msg 8

For the firt case, i'd rather prefer.
>> find/match msg join generator " OK"

hmm.. I didn't need the ( )

I use find/part because I want to match at the start of the line

of the series

Then, use find/match

But using Parse is better to my mind (less memory overhead)
>> parse msg [generator " OK" to end]

True ... but still there's a bug in find/part

Isn't there some new way to return true from parse without the "to 
end" now?