REBOL 3.0 Component Architecture

Contents

Structure

The primary goal of REBOL 3.0 (R3) is to build a lightweight, extensible platform architecture that operates over a wide variety of operating systems and devices.

There are four structural components to the R3 model:

These components are explained in the sections that follow.

Background

The Motivation for R3 was explained in detail. It can be summarized this way:

• REBOL 2.0 was primarily closed source (except mezzanine functions and protocol schemes). As a result, we (REBOL Technologies, RT) were responsible for porting all components to all operating systems, which included more than 40 systems and over 150 product executables as well as building and maintaining components such as MySQL, Oracle, ODBC, audio output, encryption, etc. This put a heavy burden on RT to keep these up-to-date and fully tested.
• For REBOL 3.0 we introduced what we call an hybrid-open-source model. The benefit of which enables the REBOL development community to add and maintain extended features, while at the same time keeping the REBOL language as a singular standard that operates identically over all systems and devices.

(1) Host Environment - Open

The host environment is the "main program" that runs REBOL.

The host can be a stand-alone program such as REBOL/View or REBOL/Serve, a plugin for a web browser, a component of a web server, an interactive development environment, or even embedded within applications and devices.

The host environment defines an operating system abstraction layer (OSAL) available over a wide range of systems, including desktop systems, set-top boxes, handhelds, and cell phones. This approach gives developers a way to use REBOL on their specific devices.

For example, REBOL may be part of a web browser plugin that gets downloaded from a web site when required. While RT may support Firefox, other browsers would be supported by members of the development community.

On the server, REBOL may be embedded within an Apache web server module or started as a Windows service or OSX bundle. Again, the range of possibilities is limited only by the motivation of developers.

(2) Runtime Core - Closed

This is the OS-independent kernel that provides the standard REBOL language across all systems and devices.

This is what makes REBOL operate identically over all systems and devices; therefore, we're strict about it. This component is not open source. If you're concerned about that, we should mention that we will continue to offer (as we did for R2) special source escrow licenses to mitigate potential long-term risks.

(3) Internal Components - Open

These are the essential built-in features of REBOL.

File access, TCP/IP networking, common network protocols, the graphical user interface, mezzanine functions, image loaders, compression, encryption, and various other functions reside in REBOL, so users don't need to import these modules.

Many of these components are not proprietary in nature and several are also OS dependent. For example, the interface to the audio playback hardware or USB serial ports must be designed specifically for each OS. As open components they can be made available on a greater number of systems.

RT provides an online source code archive, R3 DevBase Chat Forum, for developers to contribute to these components. Files can be downloaded, uploaded, reviewed, accepted or rejected directly from the R3 console.

(4) External Plugins - Open/Closed

External plugins provide extended features for REBOL.

These components are extensions for specific types of applications, so they are not a standard part of REBOL. Examples include interfaces to MySQL, Oracle, ODBC, and other database systems, loaders and savers for images, sounds, music, movies and other media, 3D libraries such as OpenGL, custom hardware, instrumentation interfaces, and more.

External plugins can be:

• Open or closed source
  Many plugins will be open source, but developers can also create closed source distributions.
• Free or commercial
  Developers are free to select the licensing model that best suits their purposes. We want to encourage free distribution models like BSD, but we also want to enable commercial developers to build and sell their proprietary products.
• REBOL and/or C code
  A plugin can be just REBOL code, C code (with REBOL native declarations), or a combination of both. For example, a plugin might add a few native functions and also several mezzanine functions or a port scheme.
• Signed and/or encrypted
  Plugins can be digitally signed and encrypted for protecting the end user as well as the developer.