You may want to use an existing one instead, the amount of issues that need work arounds with async modes is pretty big.
Also IIRC either my async:// or Romano's atcp:// work in server mode so you may want to use that instead.
Gab, was hoping to understand the basic premise, even if the caveats are muddy. I'd like to at least be able to say (to myself)--'this is the general idea, you might have trouble here, there, etc.'. While I have specific short-term goals for which my code is sufficient, I would like to have a more general appreciation of design choices even if ASYNC-MODES aren't destined for the next generation.
Also, I know you some influence in R3 ports--how much does the Rebol 3 port model reflect your ATCP/ASYNC experience?
ASYNC-MODES: 'Here be dragons!' : )
There were some nice materials in the rebol.net/wiki. Pity it is gone again. Maybe Bo could ask Carl, if he would be able to put it back online, so that we could w-get it to some different location?
Petr: if it was on the Wiki when it went down, then it'll be on this clone:
The clone above is the last iteration of the wiki. It's missing some dynamic bits (like categories, cookbooks, etc), but is otherwise the same content.
It is definitely illuminating, but doesn't answer my question...
- as to how async-modes work, it was never documented. the only documentation are my async:// and Romano's atcp:// - as to why it works that way, it was probably a kludge; only Carl knows the details - if you want to learn your best bet is to build something with it, it will then fail in a weird way, and you'll spend a few weeks trying to figure out why it failed (hopefully the existing code will give you hints and it won't be that bad...); iterate that a few times and you'll have a general idea - I don't think I had much influence on the native side of R3, my contribution was mostly the HTTP scheme, which was incomplete because I was waiting for Carl to answer some questions and implement a couple things on the native side