[REBOL] Rugby explained
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
