License

MIT license

Copyright (c) 2008, Doug Edmunds

Design Guidelines

Erlbol is client-driven. 

In other words, the client side (REBOL) initiates an exchange (send - receive) with Erlang.  The design does not handle a continual or intermittent flow of data from Erlang.

Be internally modular.

1. Erlang: Create interface code that does not require any modification of the functions that 'do the work'.  This allows for quickly 'putting a face' on Erlang code.  The Erlang functions should continue to work normally in an Erlang console.

2. REBOL: Allow for quick and easy window layouts.  Do not process data in REBOL.  Use REBOL to provide a GUI for Erlang.

Simplify the data interchange

3. Use Erlang's 'external term format' for binary data transfer between the programs.  Details of ETF are here.

Assign responsibilities

4. REBOL: Hold REBOL code responsible for sending a list of strings to Erlang, properly converted into a binary that Erlang can convert back using binary_to_term/1.

5. Erlang: Hold Erlang code responsible for turning the list of strings into appropriate data types before sending the output to Erlang processing functions.  

6. REBOL: Hold REBOL code responsible for converting the binary sent to it from Erlang into the equivalent to Erlang's binary_to_term/1.

Do I have to learn REBOL?

No, but you should look at lots of examples that create windows, then design a bunch without making them do anything, trying little changes, so you see how they look.  Once you see how easy it is to make a window (compared to using the Erlang gs module or something else), you may decide it's a small price to pay to learn more about REBOL.

The basic REBOL code example requires you to fill in the fields and click a button.  The modified versions use clickable lists to select the Erlang function.  If you compare the window layouts, you'll see there's not a whole lot of changes that you have to make to add that kind of feature. 

 

Content © 2007 Erlbol |
Powered by Etomite CMS.