Remote

Communication with other servers at the MAL level is a delicate task. However, it is indispensable for any distributed functionality. This module provides an abstract way to store and retrieve objects on a remote site. Additionally, functions on a remote site can be executed using objects available in the remote session context. This yields in four primitive functions that form the basis for distribution methods: get, put, register and exec.

The get method simply retrieves a copy of a remote object. Objects can be simple values, strings or BATs. The same holds for the put method, but the other way around. A local object can be stored on a remote site. Upon a successful store, the put method returns the remote identifier for the stored object. With this identifier the object can be addressed, e.g. using the get method to retrieve the object that was stored using put.

The get and put methods are symmetric. Performing a get on an identifier that was returned by put, results in an object with the same value and type as the one that was put. The result of such an operation is equivalent to making an (expensive) copy of the original object.

The register function takes a local MAL function and makes it known at a remote site. It ensures that it does not overload an already known operation remotely, which could create a semantic conflict. Deregister a function is forbidden, because it would allow for taking over the remote site completely. C-implemented functions, such as io.print() cannot be remotely stored. It would require even more complicated (byte?) code shipping and remote compilation to make it work. Currently, the remote procedure may only returns a single value.

The choice to let exec only execute functions was made to avoid problems to decide what should be returned to the caller. With a function it is clear and simple to return that what the function signature prescribes. Any side effect (e.g. io.print calls) may cause havoc in the system, but are currently ignored.

This leads to the final contract of this module. The methods should be used correctly, by obeying their contract. Failing to do so will result in errors and possibly undefined behavior.

The resolve() function can be used to query Merovingian. It returns one or more databases discovered in its vicinity matching the given pattern.

MODULE remote;

PATTERN remote.assert(X_0:bit, X_1:str):void;
COMMENT "";

PATTERN remote.batbincopy():bat[:any];
COMMENT "";

PATTERN remote.batbincopy(X_0:bat[:any]):void;
COMMENT "";

PATTERN remote.batload(X_0:any_1, X_1:int):bat[:any_1];
COMMENT "";

PATTERN remote.bintype():void;
COMMENT "";

PATTERN remote.connect(X_0:str, X_1:str, X_2:str, X_3:str):str;
COMMENT "";

COMMAND remote.connect(X_0:str, X_1:str, X_2:str, X_3:str, X_4:bit):str;
COMMENT "";

PATTERN remote.connect(X_0:str, X_1:str):str;
COMMENT "";

COMMAND remote.disconnect(X_0:str):void;
COMMENT "";

COMMAND remote.epilogue():void;
COMMENT "";

PATTERN remote.exec(X_0:str, X_1:str, X_2:str):str;
COMMENT "";

PATTERN remote.exec(X_0:str, X_1:str, X_2:str):str...;
COMMENT "";

PATTERN remote.exec(X_0:str, X_1:str, X_2:str, X_3:ptr, X_4:str...):void;
COMMENT "";

PATTERN remote.exec(X_0:str, X_1:str, X_2:str, X_3:str...):str;
COMMENT "";

PATTERN remote.exec(X_0:str, X_1:str, X_2:str, X_3:str...):str...;
COMMENT "";

PATTERN remote.exec(X_0:str, X_1:str, X_2:str, X_3:str...):void;
COMMENT "";

PATTERN remote.get(X_0:str, X_1:str):any;
COMMENT "";

COMMAND remote.isalive(X_0:str):int;
COMMENT "";

COMMAND remote.prelude():void;
COMMENT "";

PATTERN remote.put(X_0:str, X_1:any):str;
COMMENT "";

PATTERN remote.register(X_0:str, X_1:str, X_2:str):str;
COMMENT "";

COMMAND remote.register_supervisor(X_0:str, X_1:str):int;
COMMENT "";

COMMAND remote.resolve(X_0:str):bat[:str];
COMMENT "";