From OrganicDesign Wiki
Summary
| This summary describes an ideal of the project which is still in the early stages of research and development.
|
|
The nodal model is a distributed computing environment which has been designed for the project in accord with its philosophical foundations. These philosophies claim that all change in the universe, right down to the functionality of space and time, work in accord with a single unified principle. Distributed computing is a perfect context in which to work with these philosophies, because distributed computing is all about creating an actual real space and defining the laws that determine how its content changes.
In the nodal model, the philosophy is used to unify the runtime environment with the class hierarchy yielding a single global, self contained network of concepts (classes, prototypes, templates, forms) and their occurrences (instances), each a unique node. The physical resource aspect of this network is similarly unified; from RAM, file system and WAN, so all applications, data and their persistent storage are all part of a single changing space of nodes called the nodal network. The nodes play a similar role to object's in the common Object Oriented paradigm.
Any object is related to other associated objects (associations a.k.a key-value pairs, attributes, properties etc) which can represent active threads operating on a schedule. Active threads consume processing resource to manipulate various resources within their context in accord with their scheduled workflow. Processes at all levels are built from these workflow rules whether they're part of an application or a real world organisation.
This functionality which is common to all the objects of the nodal network is called the nodal reduction and is essentially a scheduler which replaces the traditional program flow system. Even though the nodal network is a complex application in terms of its functional requirements, it yet is able to be modelled completely as a nodally reducible structure of nodes, which means that any other applications or organisations can also be modelled in this way. In fact, the components of the nodal network are specifically designed as a re-usable universal template called generic organisation which can be extended and refined for the needs of any context.
Foundations
The nodal model is designed to offer a high level environment appropriate for representing semantic networks and executing applications directly from high-level semantic definitions. Another important aspect is the ability for the nodal-model's definition to be as context-independent as possible. This is achieved by building the nodal model entirely from a small set of conceptually simple "atomic" components similar in nature to machine code instructions. There are two main abstraction layers involved, list space and node space.
The node space level is the high-level semantic-network like environment in which we can define executable models for organisations and applications. All the functionality required to implement a node space is defined in terms of the list space functions.
List space provides a small set of functions which operate on a binary address space and offer a generic associative array. Generic means that in any item in the space, the keys of it's key:value pairs (associations) can be any type such as URI's, MD5-hashes, names (i.e. sequences of items from a particular set of symbols) or most importantly references to other items. An associative array in which keys are references to other items in the array is fundamental to semantic networks, but very few modern programming languages allow their array keys to be object references which makes runtime implementations of semantic networks inefficient. List space provides an associative memory specifically designed for runtime semantic networks, and is defined to integrate with systems directly at the machine level. It has very few functions and all are simple to port to any executable environment.
Although the list space functions are very simple conceptually, they cannot be created directly out of list-space functions as these are specific to the building of a list-space, not to describing algorithms no matter how simple they may be. But the next level up, node space is designed to generically describe algorithms, so the implementation and interfaces making up the list-space functions can be implemented within a node space.
At first glance that seems like a futile idea since having both layers defined in terms of the other is a paradox. But it's actually not a paradox because each is using the the description for a different purpose; the node-space executes it's list-space functions in "real time", but the list-space uses it's node space definitions only at compile-time. The semantic web is all about connecting with existing software in a context-independent and service-oriented way, and this used in conjunction with self-description allows a running node-space to build other node-spaces in any environment that implements its compilation process as a semantic web service. Our first priority is for each node-space to be capable of using a local C compiler to maintain it's own binary, then later we would extend this functionality to allow compilation for foreign environments and/or remote locations via SSH etc.
Nodes
Template:Node summary
Generic Organisation
The OOP paradigm was designed to allow software and systems to be designed where the description of the program which is interpreted and acted upon by the computer has a direct relationship with the high-level model of the system. Prototype-based languages make objects even more isomorphic to the real world by allowing any collections of functionality and information to be used as either an instance or a class on which other instances are based. The semantic web also extends the object paradigm by creating a universal concept network which can be knitted together in a uniform way to create standard ontologies.
As described above, list space enables these semantic networks of nodes to be operated on efficiently at runtime. Node space is a particular application of list space. It defines an environment which is similar to a normal runtime object tree, except that it is global and persistent, and semantic (the keys of key:value pairs point to other nodes), but perhaps most importantly of all, the keys are processes.
Normal objects contain properties and methods which can be executes either when an event occurs, or when the instance requires it. But in a node the keys can be connected into the schedule of processing resource. The actual functionality that a node's methods take on is defined by the key, i.e. key:value pairs (associations) are actually class:instance. This is a much more high-level and intuitive way of thinking about objects. The associations in a node are its roles, resources and information and they're persistent and continuous in nature, undergoing change over time.
All organisations, no matter how complicated are still completely describable as a set of roles, resources and processes which all work in accord with a common scheduling and booking scheme.
There is a certain level of granularity in an organisations definition which can't be broken down into smaller parts - it's considered to be indivisible, or atomic. These units of indivisible work must be carried out by the people who fill the roles, and they are expected to understand and act on the instruction. The organisational system which handles all the scheduling and booking doesn't need to understand the information itself.
Computer programs are also organisations, and any software could be completely described in the terms of an organisation, the only difference would be that the roles indivisible tasks would be filled by computer functions instead of Human beings.
The idea of generic organisation is to have a single unified organisational system that handles the scheduling, booking, process definition/execution etc for all systems modelled within it - both real world organisations, and software applications (including itself - see self containment).
Abstraction layers
Distributed spaces exhibit two fundamental abstraction layers called the logical and the physical. The logical layer is a set of unique nodes which conform to a unified addressing mechinism and make up the content of the network, this layer is akin to the objects at runtime, or the files in a filesystem or network. The physical layer is composed of a network of peers which together constitute the actual storage, processing and bandwidth resource from which maintains the existence of the logical content.
In the case of the nodal model, each peer maintains a microcosmic version of the whole network called a node space. The node space is locally available in RAM resource and is essentially a cut-down cache of the network content. Each peer runs the Nodal Reduction algorithm which determines the way the node space content undergoes change, and these changes then propagate out from local RAM to other peers and persistent storage resource. This means that the network architecture can be (and is) a nodal application which is defined as nodal reducable structure and is executed by nodal reduction.
Function execution
- Parameters
The ability to pass parameters to functions and have them return a value is necessary in a procedural language, but in an object-oriented program environment the organised object hierarchy and the ability to read and write properties within it can replace the need for parameters. For example,
- a = triangle.calculateArea(b,h)
could be replaced with statements that fill the objects properties, call the naked method which reads and writes the properties in its local scopen then the result is read from that object:
- triangle.base = b
- triangle.height = h
- triangle.calculateArea
- a = triangle.area = b
Node space
A node space replaces both the program flow aspects as well as the storage and communications aspects of application architecture.
Node
A node is like a hash table or associative array. Another way of looking at a node is as a file folder. Internally, nodes are referred to by GUIDs or node references, which are meaningful only by their distinction from each other. In the user interface nodes are referred to by names appropriate to the context in which they're being referred to. GUID's are used for referring to nodes persistently for storage and communications, but direct implementation-specific memory references are used at runtime.
Like a hash table, nodes are containers of keys and values, but because all runtime node referencing is direct, the keys and values are references, not textual names like usual.
Nodal Network
The Nodal Network is formed from communications between all the Peers. Each Peer applies the Nodal Reduction process to its local Nodal Space, resulting in the organisation of globally unique nodes identities and the propagation of change throughout the network.
Communications is a nodal organisation which extends reduction out to form a single harmonic global reduction space called the nodal network.
Large organisations involving the process and resources of many individual nodal peers rotate on larger loop cycles which are the globally known harmonics of spectrum.
- DHT-like
- Routing & Discovery methods
Nodal Reduction
A node space includes a process called nodal reduction which is an execution model, or runtime environment which uses generic organisational concepts to manage the interactions over time within categorised collections of data and functions. It is essentially the scheduler of an organisational structure which replaces the control flow aspect of program execution.
When designing applications or organisations for the nodal reduction environment, the idea is to describe as little as possible in terms of local data and functions, and as much as possible in terms of nodally-reducable structure, called processes. Nodal processes are totally reusable and independent of the target language, platform or OS-environment.
- Similar concepts
- Function bindings and references
- Nodes have a common method of describing the sequence and scheduling of processes
- Reduction
- Event model & schedule
- Persistence
- Serialise & Deserialise
- Serialise builds a textual representation of a nodes structure, this is not an atomic process
- Interface & Content
- Renderable structure, including interface event represntation
- Applicational content
old intro text
Why do we need to start at such a basic level, when powerful high-level data-structures already exist in most programming environments that can easily support this? because:
- Writing a program that uses lock-free data structures is not a simple matter of merely rewriting the algorithms you would normally protect with a mutex to be lock-free. Because lock-free algorithms are so difficult to write, researchers focus on writing lock-free versions of basic data structures such as stacks, queues, sets, and hash tables. These allow programs to easily exchange data between threads asynchronously.
- For example, consider a banking program where each thread represents a virtual teller. A lock-based approach to making a deposit could be to have one teller lock an account to make a deposit, so that two tellers don't try to deposit into the same account simultaneously. To make the process lock-free, rather than designing a lock-free "deposit" algorithm you might have the teller submit a "deposit" request asynchronously to a centralized thread that handled all deposits.
Each different programming language has it's own strengths and weaknesses across many different contexts such as efficiency, portability, scalability, availability of programmers, application-vendor support, protocol/standards support etc. But one area which is common to all languages and benefits greatly from unification is the concept of program-flow.
The concept of program-flow itself comes in many flavours which appear in all combinations across the different programming environments. Some of these program-flow concepts are subroutines, conditional-structures, looping structures, event models and multi-threading models.
The nodal model can completely replace the program-flow aspects of the environment with an organisational environment where functions and objects of other languages are managed and executed to a schedule.
The nodal model does not use methods as such, but rather is more of a code-snippet model allowing larger code-fragments to be made from executing threads of snippets. Snippets are organised by language and environment bindings.
This organisational environment is recursive, hence is not just about software, but also real-world organisations, by integrating the nodal organisational environment with our own goals, roles, and resources.
- Moment: A moment is pure instance, e.g. now. Each node exhibits a loop which passes through the current-focus of all the currently active threads in the context. In fact the only way a thread can ever execute is by being inserted into the active-loop of its parent.
- P2P and change propagation. Editing conflicts are made more of a problem in P2P due to the slow update. In a Nodal environment, editing conflicts are practically non-existent, and are easily resolved if they do occur. This is because the difficulty of the conflict is related to the size of the "atoms" involved (the smallest indivisible units undergoing change). In the case of current Wiki, CVS and most collaborative document systems is that these atoms are entire articles or files.
- See Also
Applicable concepts
Here's a list of concepts from Wikipedia which all apply to this model helping to describe what it is. The peer software...
Processing and Data Storage/Access
Each "middle" list-itemThe data structure can process, store and move information at the same time, rather than the more usual two roles (processing - data IO). The data-structure inherently handles both storage and processing. The nodal structure allows peers to use their processing ability as a generic resource.
This can happen because it is a data structure that requires processing to work, all you need to do is to call its reduce function with no parameters.
The reduce function is called to provide a quanta of processing to the system. A quanta may be thought of as the smallest unit of time/energy available to the system. Once the quanta is consumed, processing stops until the next iteration of reduction.
The functions that are executed are a set of core nodal functions that are implemented in all major languages. By analogy, in XML, the DOM allows you to implement the particular tree in runtime that is specified by the XML and offers a number of generic methods designed to analyse and manipulate trees of DOM form, i.e. you can match patterns in the tree and you can manipulate the structure directly.
The improvement we can see over the DOM object concept is not only in the efficiency of the process, but also that the notion of time is incorporated into the processing/data IO paradigm of the project, since the data undergoes change based on its structure. The programming, therefore, is replaced by collections of data that undergo change automatically due to their structure.
The efficiencies occur because the structure is inherently thin, i.e. the methods used are few and simple, as opposed to the myriad of complex methods need to manipulate DOM objects. This is because the conceptual structure of XML is far more complex than that of the project.
Resolve: (was called path-traversal, nodal-traversal)
- Accepts a path-list of nodes and traverses each in series to arrive at a final target
Peer-Space
- Harmonic Organisation
- GUID's
- Communications (aka storage & distribution)
- Sessions (moments)
To Add
// instance.create/delete(class) calls class.create/delete(instance)
// create inserts the instance into the classes instance-loop (list-aspect, next/prev)
// ie. our list of current children (that our E divides amongst) is also our instance-loop
// has or is are one, they're all just relationships that receive a portion of energy
// laster: a chain of delegate classes is created between root and the instance
// - the class of any assoc requires a portion of the quanta
// remember, next/prev and complimented by parent/current (parent is also class)
// - this allows alternate quanta be divided between parent and current, thus providing
// energy for the class->instance relationship
// - get retreives from class value if no instance value at each step of a path
// - all instance-loops work by going cd this.current then assigning this.current.next to it
// when a function executes, it can update the loop at that location (equiv to array.push)
// - a functions parameters (and even further methods and tools) are child associations
// the structures necessary to build the fucntion are child assocs too
- Threads: conversation, list of instructions, phases or cycles of operation. These phases can also loop in a cycle like seasons or days of the week. The items that make up these lists are in general called Moments. Threads are not instances, they can only exist conceptually. There can never be any such thing as an actual thread because only one part of it can exist "in the Now". It's because the thread-nature of it stretches along the dimension of time.
- Moments: A moment is purely instance. Each node exhibits a loop which passes through the current-focus of all the currently active threads in the context. In fact the only way a thread can ever execute is by being inserted into the active-loop of its parent.
- P2P and change propagation. Editing conflicts are made more of a problem in P2P due to the slow update. In a Nodal environment, editing conflicts are practically non-existent, and are easily resolved if they do occur. This is because the difficulty of the conflict is related to the size of the "atoms" involved (the smallest indivisible units undergoing change). In the case of current Wiki, CVS and most collaborative document systems is that these atoms are entire articles or files.
- See also Diff
Schedule
The schedule is used at all layers; process execution, application, people and organisations. Here we discuss it in terms of the concepts and processes which make it up.
Resource
The nodal version of the storage concept is actually Resource; the general idea of allocating, or "booking" the use of any kinds of resources to a schedule.
