The nodal model

From Organic Design wiki
Revision as of 02:58, 8 June 2006 by Nad (talk | contribs)


  1. Introduction
  • 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?


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 environments with a unified organisational environment in which the 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-snipit model allowing larger code-fragments to be made from executing threads of snipits. Snipits are organised by language and environment bindings.

This organisational environment is recursive and can therefore not only form applications from the organisation of function-execution, but also forms real-world organisations by integrating the same organisational environment with our own goals, roles, and resources.

  • Moment: 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
  1. The Nodal Model & OO
    1. +Object Oriented Programming
    2. How the Nodal Model differs from OO
  • Naming: Many problems in OO come from its foundation in naming - all the classes and objects use textual-names as their fundamental means of identity and distinction leading to problems with naming conflicts and language-dependence.
  • Instance-based: Problems arrise in OO from the fundamental difference between class and instance...
  • Unified-space: Problems arrise in OO from the runtime space not being a logical continuation of the file-system and global network spaces
  • Self-organising: Change is inherent in the network, so applications within can execute directly from their conceptual description requiring less code
  • Self-contained: Like OO, the Nodal Model is a methodology and so can be implimented in any programming environment, but unlike OO, the Nodal Model fully describes its own instantiation into those enviornments.
  1. To Add
  • 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
  1. 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.

  1. 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.