Event driven TCP / Rugby
[1/12] from: m::koopmans2::chello::nl at: 29-Jan-2002 20:10
Hi Romano,Brett
Rugby does a thing Romano described in his mail, but over one connection
(slightly more efficient).
I will remove TCP transport (speed is now the same as http), and add a
/deliver :f
with f a function that expects a value. Will work in server and view scripts
only, as you need an event loop. And of course /deliver-on-error
:error-handler
Busy busy busy....
--Maarten
[2/12] from: petr:krenzelok:trz:cz at: 29-Jan-2002 21:38
Maarten Koopmans wrote:
>Hi Romano,Brett
>
>Rugby does a thing Romano described in his mail, but over one connection
>(slightly more efficient).
>I will remove TCP transport (speed is now the same as http), and add a
>
well, what a decision ... last pure rebolish clear text form removed.
:-) So there will be no need to separately specify serve/with,
serve/with/http?
>/deliver :f
>
>with f a function that expects a value. Will work in server and view scripts
>only, as you need an event loop.
>
Very old request, but several of us feel that events belong to Core
somehow .... but - be carefull - most of us run only non GUI powered web
server. So e.g. our server has no X-Win installed - I use /Command
there. If you will make it event dependant, you suddenly killed usage of
Rugby for some XX % of servers. So, please, be carefull with playing
with IO operations you want to add ....
-pekr-
[3/12] from: brett:codeconscious at: 30-Jan-2002 8:50
Hi Maarten,
> Rugby does a thing Romano described in his mail, but over one connection
> (slightly more efficient).
> I will remove TCP transport (speed is now the same as http), and add a
Why remove the "pure" solution - where it all began?
http and tcp transports cannot share the same logic?
> /deliver :f
>
> with f a function that expects a value.
Well that should be easy to understand. :)
> Will work in server and view scripts
> only, as you need an event loop. And of course /deliver-on-error
> :error-handler
I don't quite understand why an event loop could not exist in a non-view
client script if the developer added one.
Or is that possibility still open?
Brett.
[4/12] from: jason:cunliffe:verizon at: 29-Jan-2002 16:46
> Very old request, but several of us feel that events belong to Core
> somehow .... but - be carefull - most of us run only non GUI powered web
> server. So e.g. our server has no X-Win installed - I use /Command
> there. If you will make it event dependant, you suddenly killed usage of
> Rugby for some XX % of servers. So, please, be carefull with playing
> with IO operations you want to add ....
yes very good point.
I am curious, what is the overhead on a server for having X-Win sintalled
even if running in nonGUI mode. Will stuff work ?
./Jason
[5/12] from: petr:krenzelok:trz:cz at: 30-Jan-2002 6:12
Brett Handley wrote:
> Hi Maarten,
>
> > Rugby does a thing Romano described in his mail, but over one connection
> > (slightly more efficient).
> > I will remove TCP transport (speed is now the same as http), and add a
>
> Why remove the "pure" solution - where it all began?
> http and tcp transports cannot share the same logic?
exactly :-) As Rebol grows, it will replace nowadays obscure "technologies"
:-) ... just kidding :-)
> > Will work in server and view scripts
> > only, as you need an event loop. And of course /deliver-on-error
> > :error-handler
>
> I don't quite understand why an event loop could not exist in a non-view
> client script if the developer added one.
> Or is that possibility still open?
>
REBOL/Core 2.5.0.3.1
Copyright 1997-2001 REBOL Technologies
REBOL is a Trademark of REBOL Technologies
All rights reserved.
Component: "Internet Protocols" (22-Mar-2001/17:38:17)
Finger protocol loaded
Whois protocol loaded
Daytime protocol loaded
SMTP protocol loaded
POP protocol loaded
IMAP protocol loaded
HTTP protocol loaded
FTP protocol loaded
NNTP protocol loaded
Script: "REBOL Extended Definitions" (24-Jan-2000/2:53:35)
Script: "User Preferences" (5-May-1999/7:34:03+1:00)
->> read clipboard://
** Access Error: Invalid port spec: clipboard://
** Near: read clipboard://
->> help event
Found these words:
event! (datatype)
event? (action)
to-event (function)
->> evt-port: open [scheme: 'event]
** Access Error: Invalid port spec: scheme event
** Near: evt-port: open [scheme: 'event]
The same kind of output will come from /Command console. As you can see, even
clipboard:// is blocked for both Core and Command. I think that RT could
rethink the issue and definitely move event system into core language, not
just View module. GUI events are just one of possible area of usage. I think
e.g. timers (just another example of event) belong definitely to Core ...
-pekr-
[6/12] from: m:koopmans2:chello:nl at: 30-Jan-2002 10:52
It is an addition! You can still do /deferred or sync behaviour!
--Maarten
[7/12] from: m:koopmans2:chello:nl at: 30-Jan-2002 10:57
Don't worry about this. Rugby will work on all Rebol versions.
--Maarten
[8/12] from: petr:krenzelok:trz:cz at: 30-Jan-2002 12:39
[m--koopmans2--chello--nl] wrote:
> Don't worry about this. Rugby will work on all Rebol versions.
>
cool! nice to hear. I just thought that you will use some i/o driven handler
engine, which will require events in its roots, so ... glad to hear it is just
some kind of an option ....
PS: waiting for further versions ... I can test for you ... :-)
-pekr-
[9/12] from: koopmans:itr:ing:nl at: 30-Jan-2002 12:55
On Wednesday 30 January 2002 12:39, you wrote:
> [m--koopmans2--chello--nl] wrote:
> > Don't worry about this. Rugby will work on all Rebol versions.
>
> cool! nice to hear. I just thought that you will use some i/o driven
> handler engine, which will require events in its roots, so ... glad to
> hear it is just some kind of an option ....
>
The thing is that an IO deriven engine generates "events" conceptually,
but not of event! type of course. The downside is that you cannot use the
/deliver option unless it is a view script or a script that starts a wait []
loop in some way. But I think that it is a major improvement over the current
situation.
> PS: waiting for further versions ... I can test for you ... :-)
>
> -pekr-
It will take some weeks as I am essentially doing a rewrite of 80% of Rugby.
And real life is pretty busy right now...
--Maarten
[10/12] from: holger:rebol at: 30-Jan-2002 7:04
On Wed, Jan 30, 2002 at 06:12:11AM +0100, Petr Krenzelok wrote:
> ->> read clipboard://
> ** Access Error: Invalid port spec: clipboard://
<<quoted lines omitted: 9>>
> The same kind of output will come from /Command console. As you can see, even
> clipboard:// is blocked for both Core and Command.
That's because on some platforms the clipboard is tied to the GUI engine.
On Unix, e.g., the clipboard required X11, so a REBOL version with
clipboard support can only be used on platforms with X11 libraries
installed. Having that kind of limitation in Core or Command would make
it impossible to use them for CGI purposes on platforms that do not have
the X11 libraries installed.
> I think that RT could
> rethink the issue and definitely move event system into core language, not
> just View module. GUI events are just one of possible area of usage. I think
> e.g. timers (just another example of event) belong definitely to Core ...
The event! datatype is for GUI (input) events only, not for other types of
system events. The universal i/o and signalling mechanism in REBOL
consists of ports and 'wait. Timers would be implemented using ports as
well. An "event" in its abstract notion is simply "something that
happens asynchronously". In REBOL this concept is captured by data
arriving at a port and that port signalling the arrival to a pending
'wait call.
Event-driven programming
has nothing to do with the event!
datatype. It simply describes a style in which the program waits
in a single, central place most of the time, and the program flow is
driven by external influences. In REBOL you do this by using ports
and 'wait. If you want to handle GUI events as well then ONE of the
ports you wait for is the global event-port, but other than that there
is no impact on your event loop, and it is certainly not necessary
to use the event-port to write event-driven programs.
--
Holger Kruse
[holger--rebol--com]
[11/12] from: koopmans:itr:ing:nl at: 30-Jan-2002 16:33
Exactly,
That's why you will get event-driven behaviour with Rugby on *all* Rebol
versions. You can even implement this quite simple on top of /deferred in
Rugby now yourself.
--Maarten
[12/12] from: petr:krenzelok:trz:cz at: 30-Jan-2002 18:43
Maarten wrote:
>Exactly,
>
>That's why you will get event-driven behaviour with Rugby on *all* Rebol
>versions. You can even implement this quite simple on top of /deferred in
>Rugby now yourself.
>
Well, its exactly as I said - I was confused, as usual ... :-)
Thanks for explanation, now, Holger - Cyphre's surely awaiting enhanced
timer implementation, as you mentioned in IOS conference some time ago.
So - do you have any free time around to reimplement it? Maybe next
weekend? :-))
-pekr-
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted