World: r3wp

MD5 checksums, a parser for the files (easy), and whatever they use 
for encryption.

And TCP and/or UDP.

And HTTP for tracker communication, and whatever DHT is if you want 
to support that.

http://wiki.theory.org/BitTorrentSpecification

looks like a holiday project vs a spare afternoon one!

Sometimes you want to write to the port, and then continue to write 
... so your awake handler returns false.

But sometimes for the same command, you want it to return on completion 
.. so your awake handler returns true instead.

So, .. .what is the best approach?  Pass a flag to the write?
Use a dialect for the write data block?

Isn't the return value three-state, true false and none?

I read you can only exit from the awake handler by returning true

And just for reference http://www.imapwiki.org/FrontPage

Great progress ... was able to submit a fax using my new fax:// protocol.

The fax protocol is similar to ftp but uses port 4559, and uses additional 
commands

basic IMAP4 is not much more difficult than POP3

bittorrent would be interesting indeed, as you can easily get _tons_ 
of network activity wh

which would be nice to exercise the R3 networking stack

Graham, Andreas, Steeve, et al, this is great stuff you're doing. 
Thanks for your efforts.

well, now onto the final pop3 rewrite

i've finally come up with a clean (imho) low-level interface:
mbox: open pop3://
until [empty? msg: read mbox]
close mbox

i.e. read on the pop3 port iterates thru all available messages, 
returning an empty series after the last message was read

Andreas, normaly it's the behavior of COPY to iterate thru a port 
result

i mean it is like that in R2

So 'msg is returned as a block?

I was thinking of that too Steeve. COPY versus READ versus TAKE.

Nice idea Gregg, READ could return the whole block (an COPY  or TAKE 
just one line at time)

In this case, READ seems OK, and COPY would work as well, but not 
delete the mail on the server.

read returns a binary!

bu you could return a block if you wish ;-)

Ah, so this is a native READ, not a wrapper in your scheme. Got it.

i could return all messages in a block, yes

i think i got the idea of READ iterating from some R3 example

Andreas, where is your source, is that free ?

Then we need a callback mechanism for progress, if we read all in 
one shot.

http://bolka.at/share/prot-pop3.r

[temporary url]

not yet licensed

not need of a callback, you can return a block and populate the same 
block further.
You see what i mean ?

interesting idea

I'd like to see it stay low level in the scheme, as Andreas has it, 
and add wrappers for higher level operations.

yep, i think so

we can add a series protocol later on

the source avail at http://bolka.at/share/prot-pop3.rcurrently still 
has a series interface

length? for getting the num of messages avail, pick for reading a 
specific message

I think I understand Steeve, but then how does your calling code 
know the block has been extended, without polling?

and read for the whole block (which can be updated)

Greeg, i think we could add some info in the block, like a timestamp 
at the head

hm, that'll get messy soon

perhaps it's better to return an structured object

The ability to get just headers, number of messages, etc. is great. 
Get a little info, show the user, request more data as desired, and 
show progress for lengthy ops.

progress for length ops still is an open problem

i could enable copy/part for downloading large messages

Still, without a callback or notification of some kind, the caller 
has to poll against the block to check for changes.