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

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