[REBOL] Re: Rugby for Artists => was Re: Re: Medium+ Scale Developments
From: brett:codeconscious at: 13-Jan-2002 13:36
Hi Jason,
> Well I know it is one of REBOL's secret weapons of Mass Delirium, but I
> still don't quite get it. I would welcome a beginner's explanation about
> request brokers, and expecially anything which expands on the rugby site
> documentation.
Here's an attempt (WARNING long winded).
===Why a request broker?
I'm not an expert on request brokers. My understanding is that a request
broker enables you to have one program on one machine call a function
defined in another program on another machine. The major benefit is to be
able to do so without having to write lots of complex communications code.
Calling a function on a server should be transparent to you. It should seem
as if that function resides in the same program that you are calling it
from.
===The dark times.
Historically achieving such a feat as that performed by a request broker was
considered a very big thing.
To understand why the name "Request Broker" is spoken in hushed tones you
need to know that in the dark times, people used primitive languages -
languages that could not easily speak across a network. For these people
there was wailing and nashing of teeth when from one machine they wanted
to call a function that lived on another machine.
Some other people came along. These dedicated people, motivated by not
wanting to hear highly distracting teeth noises, made a great labour of many
years to put all the communications programming that sends function names
and arguments and other necessary evils into one library/object/thing and
naturally enough a standard. And then, to refer to this great work they
called it a "Request Broker" because is seemed so active and so good at the
negotiation between the different languages and machines.
So with awe and wonderment did people bow down to the "Request Broker"
because it gave them so much. They now with their multitude of languages
could have their programs call other programs (possibly of a different
language) across a network.
But then there was grumbling, because the poor people with their cursed old
languages despite been given so much had also acquired a new burden. They
had to talk to the Request Broker in a new language (a defintion language)
otherwise it did not fulfill their requests.
But that is history. Now in these more enlightened times there is a group,
the REBOLers who use a new language which makes many communications easy.
And in particular one person Maarten has created a simple request broker
Rugby that uses the same language of these people. These people, the
REBOLers, can have their programs call functions across machines with a
single line of their code.
Unfortunately their idyllic environment is spoilt with the wails and screams
of the less enlightened poor multitude who having got sick of the Request
Broker, demand to be heard and talked to in new languages that are not
solving all their problems (xml-rpc, soap, etc).
===Rugby
Say you have a script with some functions defined and the main execution
code. Rugby allows you to split that script up to run across more than one
Rebol process (usually on different machines). You could put all the
functions in one script and place that on a server machine for example. Then
your remaining script can call the functions that now live on the other
machine.
It can do this even over a http connection. So your server based function
can be on the other side of a firewall and proxy server.
There are two sides to Rugby. Client and Server. Rugby turns function calls
made on the client into network requests. On the server machine rugby
creates a listening port (server) and converts the network requrests it
receives into function calls to the functions you wrote. The results of
those function calls are converted back to network responses and sent back
to the client. Back on the client Rugby receives the network responses from
the server and converts them into function results.
Your program code appears to have just called a function and received a
result. That's the cool bit.
===Scenarios
Think of a script you have written. Does it make sense to put some of it's
functions on a server? If so
you could use Rugby to do it in probably 5 minutes or less.
I believe Graham Chiu is using Rugby for his Gorim2 chat/game program.
Your whiteboard example. You could have one person drawing on a whiteboard
and various observers watching the changes.
Intensive calculation server. Maybe some really grunty machine (or server
farm) can do some intensive calculations - you just call a function for the
answer.
Device control. Maybe you wrote an interface to a specialised device so you
can control it from Rebol. Now you want to hook the device to a dedicated pc
across a network and control it from afar. Your script barely changes at
all. The machine with the attached device "publishes" some functions using
Rugby. Call them device-on and device-off. This script can read:
REBOL [Title: "Device controller"]
do load-thru http://www.reboltech.com/library/scripts/rugby4.r
device-on: does [ print "switch device on" ]
device-off: does [ print "switch device off"]
serve [ device-on device-off ]
REBOL [Title: "Remote control"]
do load-thru http://www.reboltech.com/library/scripts/rugby4.r
do get-rugby-service tcp://localhost:8001
view layout [
button "Turn On" [device-on]
button "Turn Off" [device-off]
]
Actually these two work, run them in a console session each. How's that? A
client and a server is so few lines of code.
Rugby does it's job so well it seems overkill to even talk about Request
Brokers.
Brett.
