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

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