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

[REBOL] Re: Rugby doco - wip

From: koopmans:itr:ing:nl at: 28-Jan-2002 14:43

Hey Brett, It is becoming more and more of a rewrite ;-)
> Hi Maarten, > > > > - What is hard for people is the notion of async programming > > > > Well up I have to admit I'll need to get it clear in my mind to be able > > to write about it :) > > Ok, I've been looking in to this a little. It essence it is event-driven > programming. A View GUI application is an application that handles > asynchronous events - user actions like mouse + keyboard. These > events are produced by the user in response to requests (screen > displays) made by the application. A twisted view perhaps, but > reasonable is it not?
Yes. So obvious I missed it....
> View gives developers three features to handle these > asynchronous events: > *event types > *the "Feel" object with its event classification > methods and a dispatch system to call them > *the event processing chain through "insert-event-func" > > Rugby handles asynchonous network events and gives the developer: > * a ticket number > *a function to check if a result is available for a given ticket > * a function to retrieve the result associated with a given ticket > > Thus a big difference for understanding the two is that: > * View makes an event "concrete" using objects and it dispatches > these events to developer defined functions. > *Rugby "eats" the event and instead focusses on providing a > pidgeon hole (ticket) for the function results. > > This means that currently a Rugby developer has to, in effect, re-create > the consumed event through polling. I wonder then, if Rugby provided a > dispatch system, whether it would be more understandable. Please note, I'm > quite unaware of the impact on the Rugby design this idea implies.
As I said in one of my earlier mails, I am adding a 'task' system to the IO engine. One of the always present tasks could be.... delivering an event. Easier, more transparent, developer friendly.... Or should I make it a Pro feature ;-) (I won't)
> What do you think? I'm prepared to be told that I've missed something > crucial and valuable :)
You haven't. You made my to be implemented list longer, but this is very valuable to all of us. It may take some time to get this done, but I'll get there. --Maarten