Killer App in REBOL - rugby
[1/3] from: petr:krenzelok:trz:cz at: 12-Aug-2001 0:57
----- Original Message -----
From: "Maarten Koopmans" <[m--koopmans2--chello--nl]>
To: <[rebol-list--rebol--com]>
Sent: Friday, August 10, 2001 8:50 PM
Subject: [REBOL] Re: Killer App in REBOL
> Hi,
>
> I doubt the need for XML based protocols. As Graham showed, you can
> hand-code that integration easily.
>
> IMHO, the Zen of Rebol is:
>
> - data and code is mixed. Everything is meta.
> - Networking is so easy that you can make distributed applications in a
day.
> All major network protocols are supported, as is database and encryption,
> which gives a pretty complete feature set for most problems to solve.
>
> The real problem we face is thinking about our problems. If you put Rebol
to
> work at its full power you get amazing things. For example, Rebocalc in
the
> script lib combined with Rim or Rugby. As Rebol is more or less a
> generational leap forward it is pretty tough thinking about the killer app
<<quoted lines omitted: 4>>
> My feeling is that the killer app will need to be distributed to expose
> Rebols full potential, but that's just a that: a feeling. This is the
reason
> I put so much effort into Rugby (plus the fact that it makes my
proffesional
> life very easy).
OK, so how does Rugby suits following task/how difficult would it be to
achieve?
your app/server (rugby) takes connection from let's say webserver. You know
you have to perform some task(s). The basic problem seems to be server
overloading, right? I am interested in ability to divide tasks (requests)
amongst several local/remote another tasks:
webserver
|
| (fastCGI)
?
Rugby server (ability to lauch new instances of clients, or connect to
remote ones, load balance (not all that necessary :-), some settings, e.g.
limit of request per task, etc.
|
----------------------------------------------------
-----------------------------
| |
| | |
local task1 local task 2 local
task 3 | |
(each performing e.g. 10 multiplexed tcp
? ?
remote task even another remote rugby server (node)?
Having threading would be probably interesting too, but even current Rebol
abilities (launching new instances, multiplexing over tcp connections, etc.)
are interesting enough ...
> I do have a nice name for the next killer app though: Rebella (and now
> picture a Lara Croft like icon). Marketing dept. is ready ;-)
CindeRella :-)
-pekr-
[2/3] from: m::koopmans2::chello::nl at: 12-Aug-2001 10:08
let the client do the load balancing:
ports: [ some ports here ]
rexec/with [ echo "la" ] pick ports random 10
[3/3] from: petr:krenzelok:trz:cz at: 12-Aug-2001 21:27
So, Maarten, have you solved your FastCGI load issues? I mean - I can serve
3 requests (tested on the largest business case of our company) per second,
which is not so much. So other clients will wait. I haven't even tried
multiplexing tcp connections, because I do work with ODBC, which doesn't
handle multiple requests from one port.
The strange thing also is - pressing imediatelly reload button causes simple
wait loop as in FastCGI Rebol docs to crash the script (reported already to
feedback).
Do you thing it would be good (sufficient) to use Rugby as FastCGI listening
server on one side, and client/server database related distributed
mechanism? I am still a little bit confosed in what would be the best (the
most efficient) set-up.
I would like to know - in your Rugby set-up - do you use Rugby server to
launch (control of launch) new instances of Rebol on local/remote machine? I
can imagine two Rubgy servers, talking thru secured line, dynamically
controlling/launching/killing instances of rebol clients, performing various
tasks ....
-pekr-
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted