• Requirements
• ModGo-Specification
• Implentation
• ModGo-Installation
• ModGo-Library
• MGO-Toolset

ModGo (Modular Go) is an extension to the Go programming language. It is designed to facilitate programming of nodesin a mobile and distributed environment. Programmers can develop a ModGo module, which is a valid Go program consisting of resource and process definitions, with ModGo annotations. A ModGo module definition is translated to an instrumented Go package. Such Go packages can be uploaded to a code repository such as github.com. Later, users can deploy ModGo modules (technically, Go packages) into a ModGo node. A ModGo node is a container of ModGo modules (and their resources and processes). It is simply an executable which hosts the ModGo runtime, where runtime is responsible for handling all requests to its resources and processes.

A ModGo resource is a service which can be used locally or by remote ModGo nodes. There are four types of resources: properties, events, timers, and functions. A property is a variable whose value can be accessed from remote nodes. It can have any primitive datatypes (such as int, uint32, bool, string) but currently ModGo does not support complex datatypes such as struct. An event is a special class of variable which can be triggered through a special function. A timer is another special class of variables which is triggered when the specified amount of time elapses. Finally, a function is a piece of parameterized code which can be called from remote nodes.

While ModGo resources are passive code of data or code which is activated only by other nodes (or other code), a ModGo process is a code which runs by itself -- so we can say that these are active piece of code. A process are the initial starting point which can initiate the function calls or resource access -- just like main() function in a C program is the starting point of every thread, a ModGo process is a starting point of all activities. Users are allowed to stop, resume, kill processes.

Typically, a process begins execution when the node starts. There are several typical uses of processes. One is for initialzation.

//modgo:proc func InitProc() { dothis; dothat; }

This process will run at the beginning of process and finish execution.

A more interesting and common type of process is a reactive process.

   //modgo:proc
   func WaitProc() {
     for {
       MG.Wait("node0", "BatteryLow");
       SendEmailToMaster("node0 is battery low");
     }
   }

This process will wait for an event and do something repetitively.

Another really interesting usage is to build a state machine using a process. ModGo provides some special system events which will facilitate some reactive programming.

A ModGo process is a Go function which is reactive to events. The function is automatically invoked whenever the event bound to the process occurs.

A ModGo module, a central notion in the ModGo system, is a container of resources and processes. ModGo users typically define ModGo modules and compile them into a Go package. Later, such Go packages can be imported from a pure Go program or a ModGo Module.

A ModGo module is a Go package which defines resources and processes. Also, it is a unit of installation (and uninstallation) in ModGo nodes.

A ModGo namespace is a set of ModGo resources -- it is basically a mapping from resource names to nodes which contains the resources. In ModGo, namespaces can be considered as a bus through which nodes interact by sending requests to resources.

A module, which is technically just a Go package with ModGo annotations, is the unit of deployment (i.e. instantiation in ModGo nodes). A module can contain declarations or definitions of ModGo resources.

   package MyModule // modgo:module

• Birth of a module: A ModGo module can be compiled using modgo command-line tool. After successful compilation, user can upload this code into a code repository such as github.com. Since this is a valid Go program, it should have a URL through which one can "go-get".

• Module deployment (instantiation): A module, which is uniquely identified by a Golang URL (e.g. github.com/mvcode/modules/counter), can be deployed to a node using the modgo tool (or programmatically through special function calls). When a module is deployed, a few parameters need to be filled in:

  • instance name: A module can be deployed (instantiated) multiple times in a single node. Each instance will have a separate state (e.g. the values of properties can be different). To distiguish between different instances, a unique name is associated with each module instance.
  • namespace: User should provide the namespace in which the given module will be active. The namespace must be ensured to be unique by the user -- any naming scheme can be used but to avoid name conflicts, some hierarchical name could be used, e.g. /mvcode/home/garage.
  • namespace password (tentative): this password is used to join preexisting namespace.

• Module activation and deactivation: A module is activated whenever the node where the module is instantiated is turned on. However, it doesn't necessarily mean that the resources in the module will be accessible by remote devices. Module resources in a node, say A can be accessed by a remote node, say B, only when they are connected -- i.e. both A and B is ON and their namespace is connected (?). A module can be active in at most one namespace at a time.

Some important meta-level life events are available as system events so that users can define a special behavior. Some callbacks, with predefined names (e.g. OnActivation) can be defined in modules.

Unlike statically-scoped programming languages, such as C++ and Java, the notion of namespace is dynamic. However, still this notion is a first-class citizen in ModGo -- i.e. it's tangible. A namespace is dynamically formed when at least one node (which can access the namespace) exists -- the first such node becomes the master of the namespace. Any node which is capable of access the node (i.e. the node where the module which can access the node is deployed and has eligible persistent module state (e.g. authenticated password)) can join the given namespace anytime it wants.

All resources exist only relative to a namespace. If some code wants to access a resource, it needs to get access to the namespace first -- this enforces some security measures. A namespace is a first-class citizen in ModGo so it can be generated by some module code itself and then, used in another module. For example, a ModGo module can define some protocol for joining and leaving a virtual network, where the virtual space is essentially a namespace.

In traditional (non-distributed) programming language, the notion of machines which executes the

In statically-scoped programming languages (which includes most popular languages such as C++ and Java), the name resolution is static. In some dynamically-scoped languages, such as Lisp, the resolution of a name can differ from run to run. In ModGo environments, the resolution of a name is dynamic in the sense in which namespace the module (which contains the resource) it is taking part.

Let two different nodes, A and B, be given. Each of them contain modules instantiated using the same namespace, say "/jason/home/bathroom". When each node is turned on, they will form each form a namespace "/jason/home/bathroom". However, they are initially separate namespaces so they don't know each other. Even if A's module contains a resource named "light", B cannot access that.

Two namespaces of the same name can be merged into a larger namespace in following occasions.

A namespace, statically, is defined by a rule which defines who can access the namespace.
A namespace can be formed in different scales (e.g. a proximal network, LAN, WAN). Also, a namespace is the unit of security enforcement. A namespace can be nested?

A namespace can form an hierarchy -- i.e. a namespace can have the parent namespace.

• Joining namespace: When a node joins a namespace, all modules will be checked if they are interested in the given namespace.If yes, they will let them publish their resources to this namespace. By doing this, all handshaking between interested parties in the given namespace happens.
• Leaving namespaces:

• SYSE_NAMESPACE_JOINED(namespace string)

Namespaces are just a special property. A namespace is implemented by a special built-in ModGo module. So, users can define their own rule for namespaces by replacing the namespace module.

A function is code which can be invoked either from the same node or other nodes.
The body of a function can contain calls to remote functions.

There is no enforcement of static type checking. The types of argument will be checked dynamically during run time.

When a function is invoked, it can be executed at most once. When any of the node in the call chain becomes inactive in the given namespace, the entire call chain is canceled.

• SYSE_NETCONN(net NetInfo)

A reactor is code which is defined inside a module. It is a event handler which is executed when a specific event is triggered. An event to which a reactor will react can be specified in two different ways: (i) bound at compile time; (ii) dynamically bound during module instantiation; (iii) dynamically bound during module activation time.

A node is a entity which runs ModGo runtime. Typically, one can think that a node represents a standalone host or a device which is executing the ModGo runtime. A single linux host running multiple ModGo runtimes (at different addresses) is also possible. Each node has a unique node ID for its identification.
Basically, a node is a container of module instantiations, where each module provides services to other nodes and reacts to events in other nodes.