[REBOL] why Rugby uses async I/O
From: m::koopmans2::chello::nl at: 23-May-2001 19:05
First of all, it's there and it's the best solution for what Rugby needs to
do, IMHO. If it breaks with 3.0, too bad. It took me a day to write it, and
if 3.0 improves the API it will take less than a day to change it. But 3.0
goes into the category "more than 6 months away", so I'll live on the edge
for now.
Second, Rebol is its own reflexive metalanguage. So once a thing like async
I/O is there, the rest is syntactic sugar. Why change the API? Why not
built on top? I know, this is the discussion you don't want (Holger), but I
can always ask ;)
I don't like the "don't use" mantra. If it's there you may use it at your
own risk, once you know the risks. An API change is the least problem in a
productive thing like REBOL. Lack of features is much more serious. So why
should yourself in the foot (RT)?
One more thing: copy/part on an async port seems to eat up memory (hence I
use read-io), bug?
Finally, I'll update Rugby to the 3.0 APIs once it gets here. Right now I am
adding security for the Pro users, top-level mezzanines, and deferred client
calls (non-blocking). Coming soon to a computer near you...
I am looking into SOAP support. Any help there is appreciated! I am thinking
of a CGI front-end that utilizes Rugby and provides SOAP marshaling. Once I
have that we are ready to blow away .Not
Speaking of publicity then :)
--Maarten
