World: r3wp

problem is, there's no event device on linux yet, whereas there is 
one on win32

that's why with linux r3, a simple "WAIT 10" will happily consume 
100% of one core for 10 seconds

bad

yep

so, here's a first update: http://bolka.at/share/prot-pop3.r[temporary 
url]

A remark. You don't need to convert string rules into binaries when 
you parse a binary

where?

when you parse CRLF for example

bom and eom

the can stay as strings

*they

that's gone in the recent rev anyway

and at least for FIND that's not true

in the PICK actor, I yet see them

refresh, then :)

ouch :-)

Andreas .. regarding IMAP4, I looked at the RFC and then revised 
RFC and then the corrections to the revised RFC .. and I thought 
.. maybe it's going to take some time to read!

I haven't used IMAP4 for years so ... for me it's going to take time 
to get up to speed again.

Also just looking at your code ..  my understanding is that if you 
request a message, you have to keep reading until you hit a  crlf 
".," crlf  sequence ... but I don't see that anywhere in your code.

crlf "." crlf

the most recent version doesn't currently fetch messages, yes

going backwards :)

most definitely :)

How would you suggest I approach the issue I raised above?

viz. Sometimes you want to exit from the handler after a messsage 
and sometimes you don't ...

Hm, could you be a bit more concrete? Give an example for the kind 
of write, maybe?

Maybe I'm wrong .. and you always want to return true after some 
data is returned

I'll work on that assumption :)

ok :)

Just remembering my Cerebrus pop proxy anti-spam script .. I had 
both progress meters for both messages download and message download

yeah, i'm still undecided how to best model that

so some standard way to provide callbacks on data transmission would 
be good

currently we have read, read/part and maybe copy/part in our arsenal 
of avail tools

but overall, i think a more general awake handler would be the way 
to go

well... we can handle this in the event handler ...

but .. we still need a way of defining these so that the user can 
access them.

eg. a user defined on-write callback and a on-read callback

or maybe a user defined event handler that we pass fake events to 
..

real events would be even better :)

I guess the first thing is to try and get them to the level of the 
r2 schemes in terms of user use

If anybody wants to start torrent protocol, here's simple *.torrent 
parser: http://box.lebeda.ws/~rebolek/rebol/torrent.r

:)

that would be awesome  :-)

write read torrent://file.torrent  %file.avi

url is wrong, obviously... but just the idea of it being this simple 
 ;-)

I could use the .torrent file parser now, even before we start writing 
the protocol, to do file management utilities.

Maxim, wouldn't it be open instead of read?

OPEN would assume rebol knows how to decode the binary data downloaded 
by the protocol.. 

can OPEN handle an avi file as we speak?  I don't think so.

You are opening the port, not the file. Torrents are both clients 
and servers. You would probably open a port spec, which would open 
as many sub-ports as needed. Closing the torrent port would close 
the whole torrent session. There would be a flag in the torrent port 
that would indicate whether the file had completed downloading.

Maxim, OPEN works on ports. LOAD is what would require a decoder 
- OPEN doesn't decode anything.