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

[REBOL] Re: Rugby integration (was) Re: Re: ANN: Rugby configurable (with compre

From: koopmans::itr::ing::nl at: 20-Feb-2002 12:46

On Wednesday 20 February 2002 09:56, you wrote:
> > > 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 - >
You are right. But RUgby was Inter-REBOL to now.
> - 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. >
On your OTOH: Yes. The plugins are actually the handlers on top of hipe. Consider Rugby itself a plugin. RebXR SE is just another.
> - 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 :-) >
I could see if I can make the checksumming optional in the config dialect. The [*** and ***] are in the post variable, which is a string, as begin and end-point markers. That should be no problem. OTOH, I may develop the Rugby bridge on top of hipe. Just a different handler ready to rock with the rest of the world. What would such a protocol look like (I ask you as you live in the world that needs it). Surely HTTP based, but then?
> 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? >
I agree. And then marshaling libs in java, perl and whatever. Rebol rules ;-)
> -pekr-