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

Rugby doco - wip

 [1/13] from: brett:codeconscious at: 28-Jan-2002 18:29


Hi Rugby team, I've made a start at some Rugby documentation as promised. Here's my first output (not complete). I'd appreciate comments. http://www.codeconscious.com/rugby/rugby-doc.html The source of which is: http://www.codeconscious.com/rugby/rugby-doc.txt Thanks Brett.

 [2/13] from: koopmans::itr::ing::nl at: 28-Jan-2002 9:46


Hi Brett, Very cool, thanks! THis will help (hopefully) Some remarks: - Is it a good idea to include a link to the download sites? - Security: perhaps talk about the /restrict refinement and secure-serve? - What is hard for people is the notion of async programming (that's what I learnt from working with Graham). Although there is /deferred, nobody (knows how to) use it. - A P2P sample? As for the architecture document.... I am currently making some heavy changes to inner rugby, such as: - Adding modules - A simple task based system in the IO scheduler, which allows you to add tasks (chunks of Rebol code) to a queue that will be executed if there is no IO. Very simple threading ;-) - This will be used by redirect, the function for server chaining. Once things have settled down in that coding area I'll produce an architecture document, with protocol specs as well! --Maarten On Monday 28 January 2002 06:29, you wrote:

 [3/13] from: petr:krenzelok:trz:cz at: 28-Jan-2002 10:08


Maarten Koopmans wrote:
> - A simple task based system in the IO scheduler, which allows you to add > tasks (chunks of Rebol code) to a queue that will be executed if there is no > IO. Very simple threading ;-)
Well, I am not sure, what is this one good for? :-) Even if scheduler will find some free time-slice to do some rebol code, you can't preempt running rebol code, so your low-priority-task can in fact block Rugby, if it is not done with its job in an acceptable period of time, no? ... -pekr-

 [4/13] from: brett:codeconscious at: 28-Jan-2002 20:30


Hi Maarten,
> - Is it a good idea to include a link to the download sites?
Most definitely. I'd like to complete it a bit more before deciding on actual URLs though.
> - Security: perhaps talk about the /restrict refinement and secure-serve?
Very good idea. Though maybe I should just link to a more reference manual/user guide type document that could be updated independently.
> - What is hard for people is the notion of async programming (that's what
I
> learnt from working with Graham). Although there is /deferred, nobody
(knows
> how to) use it. > - A P2P sample?
Well up I have to admit I'll need to get it clear in my mind to be able to write about it :) Maybe Graham (hey Graham?!) could point out some topics/difficulties that should be addressed.
> As for the architecture document.... I am currently making some heavy
changes
> to inner rugby, such as: > > - Adding modules > - A simple task based system in the IO scheduler, which allows you to add > tasks (chunks of Rebol code) to a queue that will be executed if there is
no
> IO. Very simple threading ;-) > - This will be used by redirect, the function for server chaining.
Sounds sophisticated.
> Once things have settled down in that coding area I'll produce an > architecture document, with protocol specs as well!
Great!

 [5/13] from: koopmans:itr:ing:nl at: 28-Jan-2002 10:40


You are right, but I need it for some inner Rugby. And I'll be sure not too make that kind of mistakes ;-) Will be advanced stuff for experts ;-) --Maarten On Monday 28 January 2002 08:08, you wrote:

 [6/13] from: brett:codeconscious at: 29-Jan-2002 0:18


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? 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. What do you think? I'm prepared to be told that I've missed something crucial and valuable :) Brett.

 [7/13] 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
<<quoted lines omitted: 7>>
> 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:
<<quoted lines omitted: 15>>
> 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

 [8/13] from: rotenca:telvia:it at: 28-Jan-2002 15:05


Hi, Brett
> Thus a big difference for understanding the two is that: > * View makes an event "concrete" using objects and it dispatches
<<quoted lines omitted: 5>>
> dispatch system, whether it would be more understandable. Please note, > I'm quite unaware of the impact on the Rugby design this idea implies.
Is this what you want? - client send a request to the server port and ask for an anwer on a given port - client go to wait on his port - server awakes for the client request and makes what the request asked - server send an answer to the client port - server wait - client awakes because receveis the answer So the "ticket" should be only a client port to wait for. This is the mode in which async code was executed by ARexx on old Amiga. --- Ciao Romano

 [9/13] from: brett:codeconscious at: 29-Jan-2002 11:19


Hi Romano,
> Is this what you want? > > - client send a request to the server port and ask for an anwer on a
given
> port > - client go to wait on his port
<<quoted lines omitted: 4>>
> So the "ticket" should be only a client port to wait for. > This is the mode in which async code was executed by ARexx on old Amiga.
That looks pretty elegant. It confirms (in my mind) that in async-io the site (function/port/ticket) of the receipt is different from where on the client the request originated. I don't know what the features/consequences are for the different implementation strategies - so I leave to Maarten and others to work out what the implementation should be. Thanks! Brett.

 [10/13] from: brett:codeconscious at: 29-Jan-2002 11:19


Hi Maarten,
> It is becoming more and more of a rewrite ;-)
Oops!
> You made my to be implemented list longer, but this is very > valuable to all of us.
I don't intend to add to your workload - promis :) Maybe Romano's Arexx reference simplifies it again? I don't know.
> It may take some time to get this done, but I'll get there.
Thanks for your determination. But don't "bust a gut". The world will not stop if it all that you want to do is not finished straight away. Cheers Brett.

 [11/13] from: petr:krenzelok:trz:cz at: 29-Jan-2002 6:04


Romano Paolo Tenca wrote:
> Hi, Brett > > Thus a big difference for understanding the two is that:
<<quoted lines omitted: 17>>
> So the "ticket" should be only a client port to wait for. > This is the mode in which async code was executed by ARexx on old Amiga.
That's nice, excempt, imo, above scenario looses capability of getting thru firewall, because of custom = non 80 port Rugby is supposed to connect back to. Anyone? -pekr-

 [12/13] from: rotenca:telvia:it at: 29-Jan-2002 14:04


Hi Brett,
> That looks pretty elegant.
ARexx is the best scripting language i have ever used. I always ask to myself what has done its author after it. It was also bug free after a few release. --- Ciao Romano

 [13/13] from: rotenca:telvia:it at: 29-Jan-2002 14:12


Hi pekr,
> > This is the mode in which async code was executed by ARexx on old Amiga. > > That's nice, excempt, imo, above scenario looses capability of getting thru > firewall, because of custom = non 80 port Rugby is supposed to connect back
to.
> Anyone?
Client port could be 80, the message arriving has an unique ID created by user and copied by server to mark the answer message (on Amiga ports was free - only memory limited them - in TCP they have a limit, perhaps it should be better to use ID instead of port number). To think the message like an object, it could be: message: make object [ adress: 123.24.35.5 portnum: 80 id: 1234 ;integer or issue body: [] ] ---- Ciao Romano

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted