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

[ALLY] REBOL Modules Doc

 [1/13] from: carl::rebol::com at: 31-Jul-2000 13:24


--=====================_951290263==_ Content-Type: text/plain; charset="us-ascii" Jim just reminded me that I promised to say a few words about REBOL Modules here on the ally list. I'll do better than that: Here's a short document that describes REBOL modules. Take a look. -Carl --=====================_951290263==_ Content-Type: text/html; charset="us-ascii" Content-Disposition: attachment; filename="modules.html" <html><title>REBOL Modules </title><body><font face="arial,helvetica"><h2>REBOL Modules </h2></font><p><b><pre> REBOL Enhancement Proposal: REP002 Version: 1.0.1 Author: Carl Sassenrath </pre></b> <HR><P><font face="arial,helvetica"><h3>Contents:</h3></font><p><blockquote><font face="arial,helvetica"><B><A HREF="#section-1">1. Overview </A><BR><A HREF="#section-2">2. Context Binding </A><BR><A HREF="#section-3">3. Creating Modules </A><BR><A HREF="#section-4">4. Module Hierarchy </A><BR><A HREF="#section-5">5. Module Reflection </A><BR></B></font></blockquote><HR><A NAME="section-1"></A><p><font face="arial,helvetica"><h3>1. Overview </h3></font><p><blockquote>A REBOL module is an independent context - a namespace. Modules are similar to objects in that they associate variables with values. However, modules extend beyond objects in the following ways: <p> <ul><li>You cannot access the variables of a module unless they have been explicitly exported nor can you access the word list of a module (as in the first of an object). <p> <li>Modules include descriptive blocks that define the module title, date, version, and other reflective information. <p> <li>You can create modules that act as a global environment, shielding the words above it from direct access. <p> <li>Your scripts can be defined as modules. This is specified by script headers. <p> </ul>Also note that like objects, modules can be nested to allow nested contexts. <p> Modules should not be confused with components, which are the plug-in feature-sets of REBOL. However, a component may include one or more modules. <p> </blockquote><HR><A NAME="section-2"></A><p><font face="arial,helvetica"><h3>2. Context Binding </h3></font><p><blockquote>The module design allows for varying degrees of context binding. You can control how free words (non-locals) are bound. <p> <blockquote><table cellspacing=0 border=0><tr><td valign="top" width="80"><B>Strict</B></td><td valign="top">Bind every word to the local frame. The binder will extend the local frame as much as necessary to hold all words. The module is completely encapsulated. </td></tr> <tr><td valign="top" width="80"><B>User</B></td><td valign="top">Every word that is not defined in a previous context will be bound to the local context. This allows users to get to REBOL's predefined words but have all new words bound to the local context. This is how most scripts will operate by default. </td></tr> <tr><td valign="top" width="80"><B>Explicit</B></td><td valign="top">An explicit list of local words is provided for the module. All other free words will be bound to previous frames. </td></tr> <tr><td valign="top" width="80"><B>Implied</B></td><td valign="top">Words that use SET notation at the top block level of the module will be local. All other are bound above. This is the same as object instance variables. This is the default for the MAKE module function. </td></tr> </table></blockquote></blockquote><HR><A NAME="section-3"></A><p><font face="arial,helvetica"><h3>3. Creating Modules </h3></font><p><blockquote>Modules can be created with either the MAKE function or by evaluating scripts that contain module words in their headers. <p> To create a module with MAKE, you must supply a module interface specification block and a body block. The MAKE has the general form: <p> <b><pre> new: make spec body </pre></b> The value returned from MAKE is the new module and it can be assigned to a variable, passed to another function, or returned as the result of a function. <p> <p><font face="arial,helvetica"><i><h4>3.1. Interface Specification </h4></i></font><p>The specification block is a header that is similar to that used with scripts. It contains a title, date, version, author, and other fields of a header. In addition, there are fields that are unique to modules: <p> <blockquote><table cellspacing=0 border=0><tr><td valign="top" width="80"><B>export</B></td><td valign="top">Provides a block of words that define the variables that can be accessed externally from the module. </td></tr> <tr><td valign="top" width="80"><B>import</B></td><td valign="top">Provides an optional block of imported words. When this block has been provided, no external words are bound within the module other than those that have been specified. This allows you to limit the module's access to REBOL functions. </td></tr> <tr><td valign="top" width="80"><B>local</B></td><td valign="top">Specifies an optional block that explicitly defines the local variables of the module. If this is not specified, then the local variables will be defined by their top level block set operations (as done with objects). </td></tr> <tr><td valign="top" width="80"><B>module-options</B></td><td valign="top">special flags used to control the level of binding for the module. For instance, the LOCAL attribute forces free variables that are not bound in any frame to be bound in the module, not bound in parent contexts. The USER attribute makes the module a top level frame (like a user frame). </td></tr> </table></blockquote>Here is an example of a simple module definition: <p> <b><pre> example: make module! [ title: "Example module" version: 1.0.0 export: [do-it] ][ data: [block of local data] do-it: does [probe data] ] </pre></b> The do-it function can now be called with: <p> <b><pre> example/do-it </pre></b> But, you cannot access the data. This line would cause an error: <p> <b><pre> example/data ** Script Error: Invalid path value: data ** Where: example/data </pre></b> <p><font face="arial,helvetica"><i><h4>3.2. Scripts as Modules </h4></i></font><p>For convenience, a script can also be defined as a module. This is done by specifying the module description as part of the script header: <p> <b><pre> REBOL. [ title: "Script Module" version: 1.0.0 module: 'script-module export: [do-it] ] ... </pre></b> When the script is evaluated, it will be evaluated as a module. All of its free words (globals) will be local to the module. <p> <p><font face="arial,helvetica"><i><h4>3.3. Variable Definitions </h4></i></font><p>Within a module, variables are defined as module-local in the same way that objects define their instance variables. You can write: <p> <b><pre> make module! [export [a]] [ a: b: c: d: e: f: none ... ] </pre></b> You can explicitly declare the variables that are local to a module (but you will also need to remember to maintain this list!): <p> <b><pre> make module! [export [a] local [a b c d e f]] [ ... ] </pre></b> All such locals will be set to NONE when the module is created. <p> Of course, if the LOCAL module-option is used, then all variables will be bound locally other than those that are explicitly imported. <p> </blockquote><HR><A NAME="section-4"></A><p><font face="arial,helvetica"><h3>4. Module Hierarchy </h3></font><p><blockquote>The new module architecture allows an enhanced context structure for REBOL and its scripts. Scripts will no longer be bound by default to the global frame (main-frame). Instead, scripts will be bound to a USER frame that is created below the main frame. This allows entire scripts and all of their functions and data to be garbage collected if they are no longer required. <p> This changes the binding process for scripts. The binder looks locally for a word, then looks up the hierarchy for the name. If the word does not appear anywhere in the hierarchy, then the module frame is extended with the new word. Effectively, free variables become module local, rather than global. <p> The hierarchy of module contexts is now defined as: <p> <b><pre> ROOT frame (natives, and C code references) SYSTEM frame (most of the mezz functions) USER frame (user script) MODULE frame (sub-scripts or make modules) </pre></b> When the USER module-option is used with MAKE, a peer frame is created to a script. The new module is placed at the USER frame level, rather than at the MODULE level. This allows you to create scripts that evaluate scripts in pristine environments. (That is, in the same environment as your first script.) <p> <b><pre> </pre></b> </blockquote><HR><A NAME="section-5"></A><p><font face="arial,helvetica"><h3>5. Module Reflection </h3></font><p><blockquote>You can obtain the header specification of a module with the FIRST function. This will return the header as was used to define the module. This also allows you to reflectively determine what words are exported by a module. You can use this to automatically generate documentation about a module. <p> <b><pre> foreach word get in first module 'export [ print word ] </pre></b> </blockquote>-End: Makespec 1.4.0</body></html> --=====================_951290263==_--

 [2/13] from: petr:krenzelok:trz:cz at: 31-Jul-2000 23:28


[carl--rebol--com] wrote:
> Jim just reminded me that I promised to say a few words about REBOL Modules here on the ally list. I'll do better than that: Here's a short document that describes REBOL modules. Take a look. > > -Carl >
Carl, sounds very promissing, although it will last a little bit to swallow the concepts. Will next official release of REBOL support modules already (e.g. /View beta 5)? btw: you are using 'variables name often, although you are using 'words name too. Is there any difference or are we just still talking "words"? btw2: as for garbage collector - how are modules "unloaded"? by 'unset modulename ? Thanks, -pekr-

 [3/13] from: robert:muench:robertmuench at: 1-Aug-2000 0:15


> -----Original Message----- > From: [carl--rebol--com] [mailto:[carl--rebol--com]] > Sent: Monday, July 31, 2000 10:25 PM > To: [ally--rebol--com] > Subject: [ALLY] REBOL Modules Doc > Here's a short document that describes REBOL modules. Take a look.
Hi Carl, what's makespec (I expect it to be a Rebol script)? Was it every released? Robert

 [4/13] from: allenk:powerup:au at: 1-Aug-2000 8:00


Q. Could security be handled in a module by module basis too? Something like ... A default user level secure applied to all modules unless there is a specific secure entry in the module header. Then by using a secure entry in the module header, we can be more specific. So we could give full access to file mod we trust without giving the same level of access to an untrusted mod. ;default user level secure [net allow file [allow read ask write ask execute] files: make module! [ title: "File Access module" secure: [net allow file [allow read allow write allow execute] ][...] testing: make module! [ title: "Untrusted Mod" secure: [net ask file [ask read ask write ask execute] ][...] Cheers, Allen K
>Jim just reminded me that I promised to say a few words about REBOL Modules
here on the ally list. I'll >do better than that: Here's a short document that describes REBOL modules. Take a look.

 [5/13] from: al:bri:xtra at: 1-Aug-2000 15:13


Carl wrote:
> Jim just reminded me that I promised to say a few words about REBOL
Modules here on the ally list. I'll do better than that: Here's a short document that describes REBOL modules. Take a look. It's nice, clean and simple. It looks to be a very clean way to enhance/extend Rebol with your own scripts. Andrew Martin ICQ: 26227169 http://members.xoom.com/AndrewMartin/

 [6/13] from: allenk:powerup:au at: 1-Aug-2000 23:18



 [7/13] from: rebol:techscribe at: 3-Aug-2000 1:07


Hi Carl, I like your module specification. It appears to be a useful tool for complex scripts. A few questions. A) Inheritance Question 1: Given your example: example: make module! [ title: "Example module" version: 1.0.0 export: [do-it] ][ data: [block of local data] do-it: does [probe data] ] do modules support inheritance like objects: example-2: make example [ title: "Example 2 module" version: 1.0.0 export: [do-it-as-well] ][ data-2: [block of additional data] do-it-as-well: does [probe data probe data-2] ] a) Can I now say: example-2/do-it b) If a module can inherit a parent module, what kind of permissions are effective for the descendant module? Question 2: If the answer to question 1a) is "YES", then given the parent module parent-module: make module! [ title: "Parent module" version: 1.0.0 export: [do-it set-it] ][ data: [block of local data] do-it: does [probe data] set-it: func [some-data] [ insert block some-data ] ] and the descendant module descendant-module: make module! [ title: "Descendant module" version: 1.0.0 export: [] ][ set-parent-block: does [ set-it "descendant's data." ] ] if I evaluate
>> descendant-module/set-parent-block
will the parent-module's data block be effected, or will an independent copy of the data block be effected that is local to descendant-module? I.e. once set-parent-block in the descendant module has been evaluated, will
>> parent-module/do-it
display the "descendant's data." string as part of parent-module's data block, or will this string only be displayed if I evaluate
>> descendant-module/do-it
Question 3: If a descendant module shares the parent module's context (i.e. parent-module/do-it will display a block that includes the string descendant's data. ), then can you include the following functionality? descendant-module make remote-module! [ title: "Descendant module" version: 1.0.0 url: http://www.rebol-remote-module-server.com/ export: [] ][ set-parent-block: does [ set-it "descendant's data." ] ] such that evaluating
>> descendant-module/set-parent-block
will connect over the Internet to the remote parent module and modify the data block that is stored in the RAM of the remote machine? Or am I dreaming? Message-based module inheritance over the Internet? Based on the pending module enhancement and REBOL's current messaging features, we need to add only two more words: the make-able type remote-module! and the addition of url as a module header field: local-module make remote-module! [ title: "Client Module" version: 1.0.0 url: http://www.rebol-remote-module-server.com/ export: [] ][ ] This would be quite useful. A simple chat type application, for instance, could be easily implemented. The chat client could look like this: The Chat Client =============== chat-client-module: make remote-module! [ title: "Chat Client Module" version: 1.0.0 url: http://www.rebol-chat-server.com/ export: [] ][ userid: none login: func [my-user-id] [ userid: my-userid signup userid ] chat: does [ forever [ either input? [ post-message userid input ] [ if new-messages? userid [print get-messages userid] ] ] ] ]
>> do chat-client-module.r ;- or chat-client.rm?
== module
>> signup "me" "chat-room-1"
== true
>> chat
given a chat server available on a remote machine that may be implemented as: The Chat Server =============== chat-server-module: make module! [ title: "Chat Server Module" version: 1.0.0 export: [ signup post-message get-messages new-messages? ] ][ chat-db: [ chat-room-1 [ users [] messages [] message-pending [] ] chat-room-2 [ users [] messages [] message-pending [] ] chat-room-3 [ users [] messages [] message-pending [] ] ] signup: func [userid chat-room] [ append chat-db/:chat-room userid ] new-message: func [chat-room] [ chat-db/:chat-room/message-pending: copy chat-db/:chat-room/users ] post-message: func [userid chat-room message ] [ if found? find chat-db/:chat-room/users userid [ append chat-db/:chat-room/messages rejoin [userid ": " message] new-message chat-room ] ] new-messages?: func [ userid chat-room ] [ found? find chat-db/:chat-room/message-pending userid ] get-messages: func [userid chat-room /local user] [ if all [ found? find chat-db/:chat-room/users userid user: new-messages? userid chat-room ] [ remove user chat-db/:chat-room/messages ] ] ] The neat thing about the module feature is that a different site may implement a different, more stable or capable chat server, and the same, unmodified chat client could have access to the improved capabilities, provided that the improved chat server continues to support the same public interface as the old one. Additional interface functions could be used by more advanced chat clients. Your module proposal is only "a few" lines of code away from remote capabilities. Do you think it is possible to extend your specification to include this? B) Can features be added to a module, such that a module may selectively expose additional functions, if asked to do so by an authorized client? i.e authentication-example: make module! [ title: ... authenticate: true export: [ authenticate ... ] authenticated-export: [ authenticated-function ] ][ authorized-clients: ["some-userid" "some-password" "some-other-userid" "some-other-password" ] authenticate: func [userid password] [ foreach [user pass] authorized-clients [ if (reduce [user pass]) = (reduce [userid password]) [ return true ] ] return false ] authenticated-function: does [ print "only accessable to authenticated modules." ] ] client: make module! [ title: .... authorization-id: none userid: "some-userid" password: "some-password" ][ authentication-example/authenticated-function ] Explanation: When client attempts to evaluate authentication-example's authenticated-function, authentication-example retrieves the fields userid and password from client and uses the user-supplied authenticate function to determine if the module is an authorized module. If so, authentication-example issues a unique authorization-id and reports it to client. This authorization-id will remain valid throughout this session. Based on this authorization-id, authentication-example permits client to evaluate its authenticated-function, which is any function that is listed in authentication-export. When client's module is garbage-collected the module authentication-example forgets the authorization-id it issued to client. B) would be a nice extension to A). Can't wait to hear from you ... ;-). At 01:24 PM 7/31/00 -0700, you wrote:
>Jim just reminded me that I promised to say a few words about REBOL
Modules here on the ally list. I'll do better than that: Here's a short document that describes REBOL modules. Take a look.
>-Carl > >Attachment Converted: "c:\eudora\attach\modules.htm" >
;- Elan [ : - ) ] author of REBOL: THE OFFICIAL GUIDE REBOL Press: The Official Source for REBOL Books http://www.REBOLpress.com visit me at http://www.TechScribe.com

 [8/13] from: rebol:techscribe at: 3-Aug-2000 10:44


Hi Volker, you wrote:
>As far as i understand, modules have inheritance und >autentification, but in another way: you can create >a submodule IN the main-module, which inherits all >bindings of its parent. then you can return this extended >module on request. >
Regarding this the module documentation says:
>Also note that like objects, >modules can be nested to allow nested contexts.
and the module documentation also says that:
>>>>>>>>>>>>>>>>>>>>>
The new module architecture allows an enhanced context structure for REBOL and its scripts. Scripts will no longer be bound by default to the global frame (main-frame). Instead, scripts will be bound to a USER frame that is created below the main frame. This allows entire scripts and all of their functions and data to be garbage collected if they are no longer required. This changes the binding process for scripts. The binder looks locally for a word, then looks up the hierarchy for the name. If the word does not appear anywhere in the hierarchy, then the module frame is extended with the new word. Effectively, free variables become module local, rather than global. The hierarchy of module contexts is now defined as: ROOT frame (natives, and C code references) SYSTEM frame (most of the mezz functions) USER frame (user script) MODULE frame (sub-scripts or make modules) When the USER module-option is used with MAKE, a peer frame is created to a script. The new module is placed at the USER frame level, rather than at the MODULE level. This allows you to create scripts that evaluate scripts in pristine environments. (That is, in the same environment as your first script.) <<<<<<<<<<<<<<<<<<<<< Note the last paragraph about the USER module-option being used with make. Since make supports the explicit assignment of USER as the parent module for a newly created module, isn't it a) likely, b) possible, c) consistent, d) desirable that the explicit make notation also permit that a module be declared as the descendant of a module at a lower level than USER, and yet at a higher level than the currently effective module context? The notation I'm asking about is necessary to enable remote modules. With respect to remote modules, it was late last night and I was rather brain-dead when I read the module documentation and wrote my message. This morning I realized that we don't need a remote-module! type. Notation-wise all we need is a url field in the module header. If REBOL detects that a url field has been defined in the header, then that should be sufficient for REBOL to realize that this module is intended as a descendant module of the module defined at that url (where we expect a REBOL process to be executing, which has evaluated the module we are descending from). The evaluation of words that are not defined in the locally executing descendant module are sent to the remote module (including their arguments) for evaluation by the remote module in the namespace of the remote module, using the physical resources available at the remote machine. This would make for a very easy way of using specialized resources on a remote machine (such as special graphic processors, or video compression boards, etc.) Imagine a cell phone running REBOL and being able to make full use of resources located on a remote machine simply by defining a module with a url field that references the url of a remote machine mainframe! ;-): cell-phone: make module! [ title: "cell phone module" url: http://www.rebol.com:6130/chat-server-module/ ][ signup "me" "rebol-room" chat ] Looks quite useful to me! ;- Elan [ : - ) ] author of REBOL: THE OFFICIAL GUIDE REBOL Press: The Official Source for REBOL Books http://www.REBOLpress.com visit me at http://www.TechScribe.com

 [9/13] from: agem:crosswinds at: 3-Aug-2000 15:12


As far as i understand, modules have inheritance und autentification, but in another way: you can create a submodule IN the main-module, which inherits all bindings of its parent. then you can return this extended module on request. ;have to read real syntax again :) hotel: make module! [export: [give-room-key]][ give-room-key: func[a][some-checks a return room] room: make module! [export: [bathing ...]] bathing: func[me][...] ... ] ] temp-home: hotel/give-room-key my-password temp-home/bathing me remote modules sounds nice :) ------------------------- [rebol--techscribe--com] wrote:
> Hi Carl, > I like your module specification. It appears to be a useful tool for
<<quoted lines omitted: 229>>
> http://www.REBOLpress.com > visit me at http://www.TechScribe.com
Volker

 [10/13] from: petr:krenzelok:trz:cz at: 3-Aug-2000 23:52


> cell-phone: make module! [ > title: "cell phone module"
<<quoted lines omitted: 4>>
> ] > Looks quite useful to me!
yes, just a few comments. your solution provides only solution for remotely placed modules. but - what about functions, objects, words? Wouldn't it be more general if we would be able to type e.g. ble: make/target image! 200x200 'url? As 'url is represented by schemes, even ram:// or ram-disk:// could be introduced to rebol. In any case, it would require REBOL to have some kind of default protocol for RPC, as not all types of schemes are suitable for such kind of behavior. future: joke: make/target function! [][call "set time 11:00"] Hey Elan, type 'joke at your console - just trust me. Hmm, what? Did nothing? Perhaps buggy. Well go to bed and start your timer Elan: ->> awake-me 06:00 pekr: Hehe, Elan will sleep a little bit longer ;-))) -pekr-

 [11/13] from: agem:crosswinds at: 4-Aug-2000 0:08


--- [rebol--techscribe--com] wrote on 3-Aug-2000/10:44:46-7:00
> Hi Volker, > you wrote:
<<quoted lines omitted: 7>>
> >Also note that like objects, > >modules can be nested to allow nested contexts.
hm. first i expected the kind of nesting like in functions and today existing objects. a: -42 b: make object! [ a: 42 b: make object! [b: a] ]
>> probe b/b
make object! [ b: 42 ] like that. even if under discussion :) but, now i read in your way, yes.
> and the module documentation also says that: > >>>>>>>>>>>>>>>>>>>>>
<<quoted lines omitted: 19>>
> script.) > <<<<<<<<<<<<<<<<<<<<<
then a [make module![][] ] is more like a [make current-module![][]] instead of "make a new empty module and look for all other stuff in the current context"?
> Note the last paragraph about the USER module-option being used with make. > Since make supports the explicit assignment of USER as the parent module
<<quoted lines omitted: 6>>
> the descendant of a module at a lower level than USER, and yet at a higher > level than the currently effective module context?
for me this means: [do %file] will change. now it will have its own context. except i say "use mine", then it behaves like todays 'do : i get its new words in my context. At least i understand this in this way: " This allows you to create scripts that evaluate scripts in pristine environments. (That is, in the same environment as your first script.) "
> The notation I'm asking about is necessary to enable remote modules. With > respect to remote modules, it was late last night and I was rather
<<quoted lines omitted: 10>>
> for evaluation by the remote module in the namespace of the remote module, > using the physical resources available at the remote machine.
i would prefer: send only the words. call for contents back. this would allow for easy callback-functions, like recursion between two contexts. it this way works ARexx, a server (spreadsheet) does what it knows and sends "questions" back. you could write [print/size/printer content :my-paper-calc-func] and get a call to my-paper-calc-func back :) handy. over the net, is this much slower?
> This would make for a very easy way of using specialized resources on a > remote machine (such as special graphic processors, or video compression
<<quoted lines omitted: 9>>
> chat > ]
i would express this like [do/at http://www.rebol.com:6130/chat-server-module/ [ signup "me" "rebol-room" chat ]] because i think make should make something new, while i see here a one-use-action in a specific context. but this is handy sometimes with objects, so why not with modules? maybe iam really wrong here. Carl says However, modules extend beyond objects in the following ways: , hm, no talking about restrictions.. the more i think about it, the more it makes sense.. Curious. Carl? :)

 [12/13] from: rebol:techscribe at: 4-Aug-2000 18:07


Hi Petr, In response to my example:
>> cell-phone: make module! [ >> title: "cell phone module"
<<quoted lines omitted: 6>>
>> Looks quite useful to me! >>
you wrote:
>yes,
:-).
>just a few comments.
Yikes!
>your solution provides only solution for remotely >placed modules. but - what about functions, objects, words? Wouldn't it be
more
>general if we would be able to type e.g. ble: make/target image! 200x200
'url?
>As 'url is represented by schemes, even ram:// or ram-disk:// could be >introduced to rebol.
I disagree (surprised?) with you, that the remote module extension is not general enough. Yes, any function, image ... that is to be shared remotely must be a) defined in a module, and b) accessed from within a module. But that is only a limitation in as much as giving the host the ability to control what he wishes to expose on his REBOL server. And that is a sensible limitation. Other than that, if you read what Carl wrote about modules, your scripts will always be evaluated in the context of some module. Remember that any script you load - if it is not a module - will nevertheless be evaluated in the context of the USER module. This means that if you wanted to create a function based on an argument-block and body-block combination derived from a remote machine, then given an evaluated module on a remote machine: remote-module: make module! [ export: [arg-block body-block] ][ arg-block: [a b] body-block: [print [a b]] ] a client could create his local function: local-module: make module! [ url: rebol://rebol.TechScribe.com/remote-module ][ local-function: make function! arg-block body-block ] Since REBOL does not find the words arg-block and body-block defined in the module local-module, and since local-module includes the url rebol://rebol.TechScribe.com, his local REBOL interpreter will connect to the remote REBOL interpreter located on TechScribe.com, at a specific port address that is defined by the rebol:// protocol, and bind local-function to a function that is created in the local REBOL instance, by using the blocks on the remote machine for the function's prototype.
>In any case, it would require REBOL to have some kind of default protocol
for
>RPC, as not all types of schemes are suitable for such kind of behavior.
Perhaps an implementation of XML-RPC would be sufficient? We really should be able to implement that right now.
>future: > >joke: make/target function! [][call "set time 11:00"] > >"Hey Elan, type 'joke at your console - just trust me. Hmm, what? Did
nothing?
>Perhaps buggy. Well go to bed and start your timer" > >Elan: > >->> awake-me 06:00 > >pekr: > >"Hehe, Elan will sleep a little bit longer ;-)))"
Hey, what time is it, oh, no, have to run. ;- Elan [ : - ) ] author of REBOL: THE OFFICIAL GUIDE REBOL Press: The Official Source for REBOL Books http://www.REBOLpress.com visit me at http://www.TechScribe.com

 [13/13] from: petr:krenzelok:trz:cz at: 5-Aug-2000 8:18


[rebol--techscribe--com] wrote:
> Hi Petr, > In response to my example:
<<quoted lines omitted: 12>>
> >yes, > :-).
:-)
> Since REBOL does not find the words arg-block and body-block defined in the > module local-module, and since local-module includes the url
<<quoted lines omitted: 3>>
> to a function that is created in the local REBOL instance, by using the > blocks on the remote machine for the function's prototype.
just one comment. Make 'url field more general. We currently have 'Needs field, which can contain block of needed components, so: If creating script=module, we could use even 'Needs, e.g. Needs: [Core 2.2 View 1.0 ODBC 1.0 rebol://www.rebol.com/module http://www.rebol.com/some-script.com] or just what if your module needs to be linked into two another modules? Then your 'url field should accept also block of urls .... Do you disagree? :-))
> > > >In any case, it would require REBOL to have some kind of default protocol > for > >RPC, as not all types of schemes are suitable for such kind of behavior. > > Perhaps an implementation of XML-RPC would be sufficient? We really should > be able to implement that right now. >
IIRC someone mentioned it already, but any results so far probably ... Cheers, -pekr-

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