ProLinga-Run Project

ProLinga-Run is a 4GL run-time engine. It is a interpreter that processes XML documents generated from 4GL logic statements by ProLinga-Validate. 4GL statements include bindings to the popular GTK+ User Interface for the GNU/Linux (GNOME) desktop.

ProLinga-Run communticates with other components in the ProLinga Network using request/response SOAP calls over a TCP/IP network. These other components include the application repository (prolingarepd) and user data (prolingadatd). Using this concept, programs appear to run locally on a machine, but in fact they can access a wide range of machines (= Web Services), centrally located in an intranet environment or anywhere in the world via the internet, to share the load and execute the application.

ProLinga-Run has been built and tested on various popular GNU/Linux platforms as RedHat Fedora, Mandriva Linux, Debian, openSUSE, Ubuntu and MS-Windows (Cygwin), but since all code is written in C++, it can be ported to all modern UNIX systems, GNU/Linux variants as well as MS-Windows and Mac O/S platforms. Since GTK+ has been ported to many UNIX and MS-Windows platforms, future releases of ProLinga-Run will include such ports as well.

Currently there are two flavours of ProLinga-Run.

  1. The Desktop/Client binary (prolingarun) that runs on a user desktop machine. This binary is called from the start script prolinga.

  2. The Web Service binary (prolingarund) that runs as a daemon and is used by the ProLinga-Web component.

In both cases, they contain the 4GL interpreter, while the desktop version also contains bindings to the GTK+ user interface. With the run-time environment I also refer to the user 4GL development environment, since it runs in the run-time environment being a development tool itself.

Interpreter

The 4GL engine processes statements that have been generated from 4GL logic by the generator. 4GL statements typed in by a developer user may look like this for instance:

SCREEN TITLE "Variable - untitled"
MESSAGE "Created new variable."
CLEAR RECORD Variable.Variable
LET F-EditCode.Variable P-EditCode(1)
DISPLAY ALL

To be able to process these statements we need to put them in a format that can be processed in an efficient way by the interpreter. When this logic is saved in the 4GL development tool, an XML document will be generated by the Validate Web Service that looks like this:

<?xml version="1.0"?>
<ProLinga>
  <Runner version="1.0">
    <Statements>
      <Statement SequenceNo="1" NextTrue="2" NextFalse="2" Command="2">
        <Arguments>
          <Argument>TITLE</Argument>
          <Argument>"Variable -  untitled"</Argument>
        </Arguments>
      </Statement>
      <Statement SequenceNo="2" NextTrue="3" NextFalse="3" Command="3">
        <Arguments>
          <Argument>"Created new variable."</Argument>
        </Arguments>
      </Statement>
      <Statement SequenceNo="3" NextTrue="4" NextFalse="4" Command="4">
        <Arguments>
          <Argument>RECORD</Argument>
          <Argument>Variable.Variable</Argument>
        </Arguments>
      </Statement>
      <Statement SequenceNo="4" NextTrue="5" NextFalse="5" Command="5">
        <Arguments>
          <Argument>F-EditCode.Variable</Argument>
          <Argument>P-EditCode(1)</Argument>
        </Arguments>
      </Statement>
      <Statement SequenceNo="5" NextTrue="0" NextFalse="0" Command="8">
        <Arguments>
          <Argument>ALL</Argument>
        </Arguments>
      </Statement>
    </Statements>
  </Runner>
</ProLinga>

Besides the statements and arguments, this document also contains control information as where to go after processing a statement. This is important when using statements like IF/THEN/ELSE or FOREVER loops. All data references also have been validated for their existence. While for the developer user it seems that the interpreter is a 4GL interpreter, in fact it is an XML interpreter. Using this format also opens the door for features as code generation and scripting. Since the XML parser used from libxml2 is as so called DOM parser, this model will work best with logic blocks of limited size. Benchmark test should tell us, but initial testing suggests a maximum of 500 lines per logic block must be set. For a 4GL this is a very reasonable limitation.