[REBOL] Re: LDC goes Rugby!
From: petr:krenzelok:trz:cz at: 23-May-2001 8:00
Brett Handley wrote:
> > dialects some way. Dialect based protocols could be cool. Imagine some
> > special purpose server - all you need is just domain based dialect ... but
> > maybe my thoughts here are not practical or applicable in any sense, as
> > noone replied to thoughts :-)
> Hah.:) Your message in a bottle did get received and BTW Maarten's did
> too - just going to take a little while to analyse it - boy he crammed a bit
> into that bottle :)
> Dialects are definitely practical and applicable but they represent a way of
> looking at things that is different to the way many of us may have trained
> our brains. Training one's brain is hard but as my first attempt the
> following is how I look at dialects in general.
> Dialect = Protocol
> Dialect = API
> Dialect = Instructions
> Dialect = Linearised object model
> In others words dialects abound already - but these are meant for
> lower-level interpreters ;-) The new thing is that we have been given the
> capability to make our own dialects in a simple fashion.
> So the trick is to get people (me included) thinking how simple and
> expressive a new dialect can be. A bit of training too in how to design the
> the grammars and interpreters would be useful too. I realise there are
> already examples but I reckon this topic is lead by the nose-ring stuff. In
> other words the Library needs a Dialect folder too. Or if one wants to be
> bold a whole new site - because dialects are a worthwhile even if one hasn't
> got the tools (Rebol Parse) to make them easy to deal with.
I thought of mechanism, which I am not sure would be efficient, but maybe Holger
could respond here :-)
- main task (e.g. rugby server) - accepting connections (e.g. FastCGI)
- there would be defined max. number of simultaneous (handled by 1 instance of
rebol) connections somewhere in config (and maybe could be changed accordingly
during run time too)
- once max number of simultaneous connections is reached:
a) other copy of LOCAL Rebol could be 'launched, connected to master by TCP port
Q: does the solution scale well? We currently have Sterling's proxy script or
Rugby available e.g., which show us we can handle connections by parts, so it
feels like "multitasking". But there is probably some limit to rebol speed,
where timeouts will get longer. So - will launching new OS task (new Rebol
instance, connected to "master" task, performing the same kind of functionality)
help to locally load balance connections handling?
b) there could be REMOTE instance of Rebol running, so task distribution could
be done thru several machines.
| | .... | |
local1 local2 localx |
local1 .... etc.
Other two question related to ports:
- I noticed that Maarten used open/direct non buffered aproach? Does it have any
advantage upon using buffered ports, e.g. "blocking" issues?
- I also noticed following piece of code. What does it do exactly, please - I
mean how does it influence port?
set-modes conn [ async-modes: [read write]]