Maarten Koopmans wrote:
>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.
>
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-
>HTH,
>
>Maarten
>
>
>
>>>>Now the question/brainstorming:
>>>>
>>>>- Main-server uses chaining to call to one of three (or more) child
>>>>servers, so it acts as proxy. Each of child servers is allowed to
>>>>maintain e.g. 20 simultaneous connections to database, or just accept
>>>>20 request from main-server. Each database query response is e.g. 20
>>>>KB, formatted http output. If we will send responses from all three
>>>>childs in parts, it means 60 responses at a time, each of 20 KB, it
>>>>means 1.2 MB - not that bad. Let's just say it is a peak on our 10 Mbit
>>>>line. But - as for webserver responses, it is a well known issue, that
>>>>it is better to send request once complete, at a time, not just in
>>>>parts - it is much faster. So, - should also child1,2,3 send responses
>>>>one at a time, or just in parts, as they build various phases of html
>>>>page? Or does it even really matter?
>>>>
>>>First "chaining" is implemented in servers. To use it in main-server
>>>you'd have to use /deferred and check with get-result in the event loop.
>>>But that should be easy.
>>>
>>And that is something I would like to discuss. In the set-up I described,
>>main-server acts as a proxy/bridge, accepting connection from external
>>systems, and doing deferred calls to child 1..3. But - that way the Rugby
>>functionality is degraded - I can't use chaining etc., as main-server runs
>>only Rugby client mode. And now one crazy idea -
>>
>>What about not reinventing the wheel and implementing my own listening
>>loop, and run Rugby server in main-server? What would be needed? Simply to
>>teach external environments Rugby protocol. So now few questions -
>>
>>- would it be possible to adapt Rugby the plug-in way (or just separate
>>versions), that would use tcp, http, xml-rpc, soap (in future for those who
>>will need it) transport mechanisms? I think that it is possible, as you
>>offer xml-rpc? OTOH this one is not probably so important (at least for me
>>now), as I looked at Visual Objects classes for e.g., and there is nice
>>HTTP class implementation. The same will probably go for Delphi, VB etc.
>>IDEs.
>>
>>- let's suppose we use current HTTP transport mechanism. Is it possible to
>>have Rugby protocol a little bit more abstracted? I mean - currently -
>>result of following line seem to be added to http header, right? But that
>>is not all, as in the case of compression internal part of Rugby message is
>>compressed, and I am not even talking checksum/secure part, which I don't
>>know how to reproduce in external language. And I am not better even
>>mentioning secured connection :-)
>>
>>cmd-string: rejoin [ {rugby-rq: [***} cmd-block {***] xtra-info:
>>"1234567891011121314} ]
>>
>>So, to sum it up - it would be nice to have external app to talk Rugby
>>language directly, as that way you can run main-server (your proxy/bridge)
>>directly in Rugby server mode.
>>
>>What do you think about it?
>>
>>-pekr-
>>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
