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
> > > 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.
