[REBOL] Re: Rugby integration!
From: petr:krenzelok:trz:cz at: 20-Feb-2002 19:58
Maarten Koopmans wrote:
>Did two minor bugfixes on rebxr and rugby in hipe.
>I realized that you can do this already:
>recho: func [s [string!]][ chain/deliver http:/localhost:8002 reduce ['echo
>which assumes that there is an echo Rugby on 8002 on localhost.
>What happens is that you have access to threading (through hipe) and can use
>chain (which is a client-side Rugby thread) if you have loaded Rugby.
Well, I do understand your scenario. Tell me just one thing - is above
scenario possible without the xml-rpc? I haven't found any xml-rpc
solutions with our VO language and I am not sure there is any for
Delphi, etc. I do really look for the possibility of turning off the
checksumming and other stuff, to be able to use tcp or http classes on
the client side, to communicate "somehow" to Rugby server, whatever
>Only problem now is delivery of the result back. But this can be solved
>architecturally quite simple by splitting a request/reply into two xml-rpc's
>and when the chain returns:
I don't understand a bit - do you mean that main-server would have to
generate reply itself? But then external app would have to be able to
accept xml-rpc requests (act as an xml-rpc server), no?
>where main server makes an explicit call to deliver the result.
>Here. Today. Man I'm happy ;-)
Yes, there is lot of potential with Rugby and dynamic capabilities of Rebol!
>If I were you I'd use xml-rpc anyway, and forget about the balancing
>initially. That can be done in so many ways that there are perhaps more
>transparent solutions than the one with the callback outlined above.
Yes, I know there are several ways of how to do it. I think that I will
initially go with Apache + FastCGI simple loop, main-server featuring
deferred calls to three pre-run Rugby servers. It's an act of an
excercise :-) Besides that - if calls to odbc port can't be async, there
is no reason for chaining using only one child, as such child will be
able to handle only one request to odbc source at a time, so other
request coming to main-server would have to wait anyway, because the
child would be busy getting data from database ...
I was disappointed that ODBC calls were blocking. The truth is I
haven't tried to open several command ports to opened database
connection, but I am not sure if it is possible ....