Async Rugby

I'm inclined to do a rewrite of hipe.r as Maarten mentions on AltME: If you use async:// you'll have to rewrite hipe.r and use Gabriele's do-after, do-every mezzanines as well. Would be great, because then there is a fully async Rugby and it *is* do-able. Kinda puts the stress on REBOL services. Note that the stub layer etc. will still work as that is decoupled from transport. as I'm constantly frustrated with the lack of async ability for properly displaying wait indicators and generally avoid program lock ups, particularly with get-rugby-service and with unreliable networks. But I'm afraid I haven't the foggiest idea how to do that. I'm looking at hipe.r, but it looks to me as if hipe is handling threading, ports, handlers and such in a way, that replacing it or rewriting it to use async:// doesn't add up for me. It seems I should attack a lower level than hipe, to do this. Any help would be appreciated. -- Regards, Henrik Mikael Kristensen

You might also just use /Services and the RPC service. It depends on your app, as /Services may not be mature enough for some kind of apps. However, I think both Gregg and Robert are using it without problems. (Robert also has an experimental version with some http proxy support - if it's working for him we can release that somewhere.) Regards, Gabriele.

I evaluated /Services early in 2006 to see whether it would be useful for my work and while it's good to code for, some nasty hangs during testing prevented me from moving further with it. I learned back then that this is possibly a design flaw in /Services, due to the lack of async and it would not be possible to fix before R3. This was since refuted as being fully possible to fix for R2, but is a priority issue (no time to fix). The docs say it's a design flaw, so I don't know what to believe. :-) But in short, it's not finished yet and I have no control over it. I do plan to move over to /Services for R3 when it gets completed. I have spent many hours writing apps around Rugby, since the beginning of 2006 and am fully depending on it now in my own development pipeline. I'm in the process of implementing solutions for customers using Rugby. I know what's going on in about 25% of the Rugby code. As I've been digging deeper into it, I've found numerous hangs, bugs and performance issues. Most are fixed and some are hard to fix in Rugby's current form, due to port bugs in REBOL. Here's an overview of what problems there currently are with Rugby, in order of priority: 1. It hangs REBOL showing 0% CPU usage when a server tries to deliver data back to the client and the client is gone. This is due to a port bug, where REBOL seems to wait indefinitely for data. If it happens, both client and server must be restarted. The risk of hang grows if the client is on a slow, unreliable connection. This is a showstopper that must be fixed. 2. It's not async. Sending 1 MB data to a 56k modem from server to client will hold up all other operations. This is fixable, but difficult. It would boost Rugby performance with multiple clients a lot. Even with number 1 fixed, Rugby is still very usable without async. 3. Not all functions and content for transmission can be sent exactly as originally written. This is a thing that you can work around. 4. Some crashes when using /secure, but these are so random and rare, that they are hard to trace. When not using /secure, these crashes don't occur at all. 5. A certain port bug (which outputs NONE! when you read from the port) means that the server reading data from the client is a bit slower than it needs to be. It has to be throttled to read less than 3 kb at a time. However the fixes I made have boosted performance tremendously over the original Rugby Version 5.0.0, which only read 16 bytes at a time and it's reliable so far. 6. The security in Rugby is not that great and can be circumvented using code injection, but no solution has yet been found. I'm not working on this, since I use Rugby primarily in a closed LAN. The hang in number 1 requires expert assistance to fix. But if at least this hang is fixed, Rugby will be very reliable when not using / secure, and it will become possible to recover from a network failure without having to restart all servers and clients. As you can see, Rugby is a better known field to me than /Services and I think I know exactly what needs to be fixed for it to be 99,97% reliable for use with multiple clients in an unreliable network. It's now a matter of how to fix it, which is where I'm stumped. :-) -- Regards, Henrik Mikael Kristensen