Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Rugby integration!

 [1/2] from: koopmans:itr:ing:nl at: 20-Feb-2002 14:14


Did two minor bugfixes on rebxr and rugby in hipe. I realized that you can do this already: do %rugby.r do %xml-rpc.r recho: func [s [string!]][ chain/deliver http:/localhost:8002 reduce ['echo s] :print] which assumes that there is an echo Rugby on 8002 on localhost. Now do: xmlrpc-serve [recho] 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. 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 client--xml-rpc--main-server--rugby(chain)--child and when the chain returns: main-server--xml-rpc--client where main server makes an explicit call to deliver the result. Here. Today. Man I'm happy ;-) 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. HTH, Maarten

 [2/2] 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:
<<quoted lines omitted: 7>>
>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 somehow means :-)
> >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 > >client--xml-rpc--main-server--rugby(chain)--child > >and when the chain returns: > >main-server--xml-rpc--client >
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 .... -pekr-

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted