PROSE and LDAP
Contents
PROSE and LDAP
The PROSE Programming Language is designed with an LDAP back-end. But what does this mean? What are the benefits?
Before we dive into this philosophy in depth, it is suggested you become familiar with an abridged description of the features of PROSE:
This article discusses the benefits of the PROSE core engine design.
Why LDAP?
LDAP is an application protocol. It is used for accessing information across an IP network from directory services that organise this information in a hierarchical fashion. It is designed to be distributed. This makes it easy for large directories to be split up and served from multiple sources.
LDAP is traditionally used for accessing miscellaneous information from a directory service that needs to be referenced often. The information is usually small, but there may be a large number of discrete items in the directory. For example, user names, passwords, access rights, locations, telephone numbers, network information. Practically any information that isn't too big and would benefit from being organised in a hierarchy and accessed across an IP network.
Now imagine that there is a programming language that implements its objects in a directory service, and which uses LDAP at the lowest level to distribute its objects across multiple sources. So, for example, one collection of objects might define an accounting program and those objects may be distributed across a number of discrete computer systems. Another collection of objects, similarly distributed, maintained by a different group of developers, might define a human resources program. Yet another branch might define common library routines. Through LDAP, program code, global variables, objects and data might be accessed and shared between multiple systems, distributed across IP networks through referrals and replication.
Simple reliance on a distributed application protocol for its core objects gives a programming language the power of distribution like no other.
PROSE is such a language. It is built with an LDAP back-end and designed to be distributed in this fashion, at the lowest level.
Hot code swapping
Now imagine that distributed program objects, accessed via LDAP, could also be hot-swapped. In otherwords, if a bug is found in a program object, a new version of that object might be introduced into the running system with no downtime. Any processors executing the original object are unaffected, as the new object is placed in a different path. However, all new code access to the object is automatically redirected to the new version. Assuming no objects are designed to run within infinite loops, the old object can be removed once there are no further running instances of it in the system.
To mitigate the problem of infinite loops, we introduce the concept of a function loopback object. This is an object, designed to run in a loop, that behaves very much like a function. If the function returns a zero status, the object is re-loaded and re-executed, maintaining local variable state. If the function exits non-zero, the object returns to the caller. The advantage of this approach is that infinite loops would not cause a problem with hot-code swapping, as each iteration of the loop would cause the object to be reloaded. Therefore if a new version of the object is introduced, it will be executed instead.
Low-level implementation
These features are implemented at the lowest level - at the bytecode level. There are bytecode instructions for navigating and modifying a hierarchical structure called the nexus. Different functionality is accessed by addressing different paths within the nexus. Code is run directly from the nexus, and all variables and objects used by the code is stored within.
Portions of the nexus can be referred to other PROSE engines, so that functions can appear to be local, while actually being implemented across an IP network.
Current status
Many of the features discussed in this article are design ideas that have not yet been implemented. Although the basic objects exist and are created within the nexus, based on an LDAP schema, there is no LDAP protocol implementation. Please see How to get involved for details of outstanding tasks and how you can help with the development of this project.
