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

[REBOL] Re: Event driven TCP / Rugby

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:// > ** 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.
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]