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-
--Maarten
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
