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

Rugby explained

 [1/4] from: carl:cybercraft at: 23-May-2001 20:56

On 23-May-01, Maarten Koopmans wrote:
> Hi List, > As I noticed some more replies to LDC goes Rugby I'd figure I'd > explain a bit more:
(Big snip since I'm just being a dumb Kiwi...:) Should I forward it to the All Blacks, do you think? -- Carl Read [carl--cybercraft--co--nz]

 [2/4] from: m:koopmans2:chello:nl at: 23-May-2001 11:18

Are they a local rugby team? Rugby: Rebols Ubiqitous and Graceful Broker, Yes! In Europe we are actually more into soccer.... Anything for a funny acronym though ;-) --Maarteb

 [3/4] from: carl::cybercraft::co::nz at: 23-May-2001 22:50

On 23-May-01, Maarten Koopmans wrote:
> Are they a local rugby team?
Yeah -
> Rugby: Rebols Ubiqitous and Graceful Broker, Yes!
Go on - you just made that up!
> In Europe we are actually more into soccer....
We know. (:
> Anything for a funny acronym though ;-)
Well, I like it.
> --Maarteb > ----- Original Message -----
<<quoted lines omitted: 16>>
>> Carl Read >> [carl--cybercraft--co--nz]
-- Carl Read [carl--cybercraft--co--nz]

 [4/4] from: m:koopmans2:chello:nl at: 23-May-2001 10:24

Hi List, As I noticed some more replies to LDC goes Rugby I'd figure I'd explain a bit more: First of all: KEEP POSTING SCRIPTS TO THE REBOL LIBRARY! (That was the religios part, on the Rugby stuff) Concepts ************** 'Hard thins should be simple as well'. The concepts behind Rugby are a mix of middleware and Service Oriented Architecture (SOA). My idea was this: you have some existing functions that you want to be available for other Rebol processes. Can I expose them in one line? Can calling them be a one line thing as well? This is exactly the same concept as lies behind SOAP and .Net, but now making such services is so much easier now. Even better, existing functions can be exposed with just one line. This should help accelerate Rebol development. CGI / SOAP ************* You can combine the Web / CGI to use Rugby from all kind of web-enabled devices. You simply post a rugby statement [ echo "dummy statement"] to the following cgi-script REBOL [] rugby-client/rexec/with do decode-cgi input <your-port-spec-here> If you are using erebol.r you can wrap this line between <% and %> in a html file as well to have executable Rebol / Rugby pages! As for SOAP, can we wrap Rugby request in SOAP? Can we use SOAP as a transport layer for Rugby. I'd say no, but... we might be able to implement a Rugby like thing with a SOAP interface. See the implementation notes on hipe. A CGI-wrapper might be an option as well. IMPLEMENTATION NOTES **************************** Rugby consists of three objects. rugby-client, rugby-server and hipe-serv. I have themin three files here but just copied them into on for the sake of the library. Rugby-client is fairly straightforward. It sends a message as a block and waits for the answer. Note that your message may only contain one function call with all parameters as values. This is because of the protected environment where services run in: if you'd allow [ echo reduce [ "lala" ]] you'd also allow [ echo reduce [quit]] or worse on the server. An obvious improvement is async i/o on the client side, so you can send the request and check back later to see if it is there. Version 1.1 :) Hipe-serv is a high performace server framework. You give it a server port and a handler function and then this happens: hipe waits on all active ports for activity. If a connection is made to the server port, the port is accepted, set to async, and added to the port wait list. If something happens on a session port, its handler is called. At the end of the road the handler is responsiblie for calling 'stop' on the session port. Rugby-server adds a do-handler, that allows you to read a message and do it. It does so as follows: it tries to read 4 bytes that describe the message length async. If it reads only two bytes, it returns and tries to read the next 2 bytes the next time activity ison the port and the handler is called. Once it nows the message size, it tries to read the message in parts. If the complete message is read it is executed in the safe-exec environment. Thus, if your function does some seriously blocking stuff the service gets blocked more or less. I noticed Jeff saying something once about simulating threads at the interpreter level (Rebol being reflexive, meta and so on), but I have no solid idea yet. Version 2.0 feature :) Now, as for hipe: you can easily add your own handler and just use hipe. Due to its async nature a serios web server is an option. Or a chat service, or a P2P presence provider (Carl?) with a MySQL backend. Or.... use your imagination. Chat and P2P can also be done (and probably more easily) with Rugby. Another nifty feature I might add is a balanced queue: the ports with more activity get more attention. Not sure if it will add more performance, but should be a nice exercition. TODO ****************** - Utilize async I/O onthe client side. - Add encryption for Pro and Command users. - Add threading thingy. - Add CGI wrapper. Hope this helps, Maarten

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