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

Rugby for Artists => was Re: Re: Medium+ Scale Developments

 [1/14] from: jason::cunliffe::verizon::net at: 12-Jan-2002 2:12


> Err, a request broker? I'll have to do some research (no need for you
to
> waste yours and everyone else's time explaining it to me ;) I'll do some > searching.. Hmm..
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. I think very visually.. so what I am always looking for is a sequence of quick napkin/whiteboard sketches abuot rugby, and how it may be used in a few scenarios, with examples. Anyone? Meanwhile a ton of google references to OMG and CORBA. Dry snippets like this: <quote> The Object Request Broker (ORB) manages interaction between clients and servers. This includes the distributed computing responsibilities of location, referencing and 'marshalling' of parameters and results. <quote> ./Jason

 [2/14] 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.

 [3/14] from: carl:cybercraft at: 13-Jan-2002 17:58


On 13-Jan-02, Brett Handley wrote:
> 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).
[snip] Thank you Brett. That's the first coherent explaination of Rugby I've heard. -- Carl Read

 [4/14] from: rondon:andrade:uol at: 13-Jan-2002 4:51


Hi Brett and Rebolers! I have a few doubts about rugby. I can make a direct call using rexec and sexec, putting the service at http layer. So I can call a service through rugby to be sent to a browser, but how can I send back args to my functions inside rugby server via my IE5? What are the variables that I must read ? Where are they located, if this is not running in cgi-mode? If you would compare the use of FastCGI and Rugby, which do you prefer to use in terms of best performance? Thanks in advance Rondon

 [5/14] from: jason:cunliffe:verizon at: 13-Jan-2002 7:47


> I have a few doubts about rugby. I can make a direct call using rexec and
sexec, putting the service at http layer. So I can call a service through rugby to be sent to a browser, but how can I send back args to my functions inside rugby server via my IE5?
> What are the variables that I must read ? Where are they located, if this
is not running in cgi-mode?
> If you would compare the use of FastCGI and Rugby, which do you prefer to
use in terms of best performance? good questions.. You may want to look into RebXR, a full client/server XML-RPC implementation for REBOL by Andreas Bolka. http://earl.strain.at/space/rebXR I am still trying to map the relationship between rugby, xml-rpc, vanilla [apache, cgi +rebol], and fastcgi. ./Jason

 [6/14] from: jason:cunliffe:verizon at: 12-Jan-2002 22:57


> Here's an attempt (WARNING long winded). > ===Why a request broker?
<<quoted lines omitted: 3>>
> Rugby does it's job so well it seems overkill to even talk about Request > Brokers.
Brett LoL :-) that's really wonderful.. thanks for de-mystifying teh subject in such an entertaining and lucid way. btw do you know Scott McCloud's brilliant cartoon-books: 'Understanding Comics' and 'Reinventing Comics' ? He has a cool website section called "I can't stop thinkning!", which folls on from the last book. Features some good discusion forums about micro-payments etc. Latest 'Wired' magazine has a small cartoon 'interview' with him as synopsis. http://www.scottmccloud.com/ http://www.scottmccloud.com/comics/icst/index.html Your article reminds me of his books a little, and makes me thing it could be good to develop a site/comicbook exploring rebol + rugby-based applications such as the ones you hint at in your scenarios. Interested? REBOL+Rugby is a technology which also seems to be answering some of his complaints about the web and hopes for what comes next.. cheers ./Jason

 [7/14] from: doncox:enterprise at: 13-Jan-2002 13:41


On 13-Jan-02, Brett Handley wrote:
> 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.
But isn't this incredibly slow compared to running the function locally ?
> Your program code appears to have just called a function and received > a result. That's the cool bit.
I would expect a noticeable pause each time. Regards -- Don Cox [doncox--enterprise--net]

 [8/14] from: petr:krenzelok:trz:cz at: 13-Jan-2002 23:36


Don Cox wrote:
>On 13-Jan-02, Brett Handley wrote: >>Say you have a script with some functions defined and the main
<<quoted lines omitted: 6>>
>But isn't this incredibly slow compared to running the function locally >?
hmm, it depends upon the speed of connection, but folks measured something like 150 - 350 echo calls per second. Not all that slow imo. But look, while someone is talking about distributed apps, Rugby is really so easy to use, that you even't don't understand why is it called distributed - it is pretty natural. Maybe you just want to ask, why should you use Rugby? OK, - you can use Rugby in Webserver + database scenario. You have webserver,e .g. Apache with Fast-cgi Rebol proces running. Apache receives some request, it sends it to Rebol fast-cgi process, and you want to perform some database query. But your database lays somewhere inside your company, on a different machine, where you just installed Rugby server, and exposed some functions for others to use, e.g. 'query-db. Then all you need on your web-machine is: do get-rugby-service tcp://remote-machine-ip:port, or you can even use secured connection. It imports function stubs onto your machine, so you can call Rugby exposed functions by they names as if they were on your local (in our example Web-server) machine. You simply don't care where the function code is, and what machine is it performing on. You just call it, and get the result ... uhm, maybe a bad example :-)
>>Your program code appears to have just called a function and received >>a result. That's the cool bit. >> > >I would expect a noticeable pause each time. >
Maybe ... but you just use the stuff upon the purpose, right? ;-) I hope you just don't expect to call pixel change function located on the remote machine and then complain the stuff is slow ;-) The best example is really a database stuff - pass a query to the db, and receive the result ... -pekr-

 [9/14] from: brett:codeconscious at: 14-Jan-2002 19:20


Hi Rondon,
> I have a few doubts about rugby. I can make a direct call using rexec and
sexec, putting the service at http layer. So I can call a service through rugby to be sent to a browser, but how can I send back args to my functions inside rugby server via my IE5?
> What are the variables that I must read ? Where are they located, if this
is not running in cgi-mode?
> If you would compare the use of FastCGI and Rugby, which do you prefer to
use in terms of best performance? First off, let me say, I may have completely misunderstood you and so my response could be completely irrelevent. More knowledge people will hopefully correct me if I'm wrong. I must admit I hadn't thought of using a browser with Rugby. But if I did, I would need to use the Rebol plugin as well. I would then put my Rugby (client) enabled script in an html page for delivery to the user. Rugby and FastCGI can both handle http requests - but those requests mean totally different things. For me, Rugby and FastCGI have two different purposes. FastCGI is used to avoid a weakness of plain CGI - that being that CGI creates a new process for each request it needs to service. FastCGI does better because it makes a CGI type program persistent (held in memory) - a very old trick from mini-computer days. Though it requires a change to the programming (something the old minis avoided). FastCGI then, is a performance tweak for web-servers. Rugby has a more specific purpose. Rugby is meant to provide network services for programs. As Maarten points out, Rugby now supports XML-RPC. So Rugby can do web services as well. FastCGI might be used for a web-service situation, but then again it might not - it might just deliver the time of day in pretty colours. Rugby is devoted to network services for programs at the language level (the level of a function). FastCGI delivers html or other content, Rugby delivers Rebol values. I have no recommendation on one over the other. I have not used FastCGI at all, I have not used Rugby in a production environment. I would normally consider them different tools for different jobs. Brett.

 [10/14] from: greggirwin:mindspring at: 14-Jan-2002 13:13


Hi Don, << But isn't this incredibly slow compared to running the function locally?
>>
Yes, but...it depends on your connection, the overhead of the marshalling, and the amount of time spent in the function, as well as the frequency of the call. Even making an out-of-process call on the same machine is much slower than an in-process call, and you *don't* want to call simple built-in routines, in a tight-loop, through a slower pipeline. However, if you're analyzing weather data for a national laboratory and you can call a routine that runs on their Cray and just gives you back a result, that's what you should do. IOW YMMV. :) --Gregg

 [11/14] from: carl:cybercraft at: 15-Jan-2002 21:28


On 13-Jan-02, Jason Cunliffe wrote:
>> Here's an attempt (WARNING long winded). ===Why a request broker? >> ===The dark times.
<<quoted lines omitted: 7>>
> btw do you know Scott McCloud's brilliant cartoon-books: > 'Understanding Comics' and 'Reinventing Comics' ?
I have "Understanding Comics", and you're right, it's very good. (Note for those who don't know it: It's about understanding the way comics work - how they flow, why they're broken up on a page in a certain way and so forth, and not about understanding the stories in comics.)
> He has a cool > website section called "I can't stop thinkning!", which folls on
<<quoted lines omitted: 3>>
> http://www.scottmccloud.com/ > http://www.scottmccloud.com/comics/icst/index.html
Many thanks for the links. Those interested in GUI or website design should check out the second one. Plenty there to make you think even if you're not interested in comics.
> Your article reminds me of his books a little, and makes me thing it > could be good to develop a site/comicbook exploring rebol +
<<quoted lines omitted: 4>>
> cheers > ./Jason
-- Carl Read

 [12/14] from: brett:codeconscious at: 15-Jan-2002 22:54


Hi Jason,
> LoL :-) that's really wonderful.. thanks for de-mystifying teh subject in > such an entertaining and lucid way.
Glad you liked it. There's hope for me yet!
> btw do you know Scott McCloud's brilliant cartoon-books: 'Understanding
Never met them. But I'll make a note to check out the links.
> Your article reminds me of his books a little, and makes me thing it could > be good to develop a site/comicbook exploring rebol + rugby-based > applications such as the ones you hint at in your scenarios. Interested?
Curious and interesting idea. Makes my mind go *wobble*. I'll let it sink in a bit before I comment :) Brett.

 [13/14] from: doncox:enterprise at: 15-Jan-2002 13:13


On 14-Jan-02, Gregg Irwin wrote:
> << But isn't this incredibly slow compared to running the function > locally?
<<quoted lines omitted: 9>>
> result, that's what you should do. > IOW YMMV. :)
I agree. But there is a tendency currently to pretend that everywhere on a network is just the same as a location in your own computer. There are always going to be delays which are vastly greater than the delay in accessing a local drive. And a WAN is of course slower to respond than a LAN. So remote calls should only be used for routines which take more than, say, 15 seconds to run, such as your weather example. You can argue over the 15 seconds figure if you like. This is not meant to be a hostile criticism of Rugby, just to point out that there is no magic. Regards -- Don Cox [doncox--enterprise--net]

 [14/14] from: greggirwin:mindspring at: 15-Jan-2002 11:50


Hi Don, << This is not meant to be a hostile criticism of Rugby, just to point out that there is no magic. >> Agreed. There is no solution which will work in every situation. I guess I would say that if you decide some part of your app should make remote calls, Rugby is up to the task as well as any other remote execution approach. --Gregg

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted