|
|
| (56 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| − | [[Category:Nodal Concepts]][[Category:Stubs]]
| + | <noinclude>{{glossary}}{{legacy}}</noinclude>The [[nodal model]] is a [[w:Distributed computing|distributed computing]] environment which has been designed for [[the project]] in accord with its [[:Category:Philosophy|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. |
| − | <table class=msg><tr>
| |
| − | <td style="width:0;padding:15pt 0 0 10pt;">[[Image:Alert.png]]</td>
| |
| − | <td style="margin:0; padding:0 15pt 0 15pt;">
| |
| − | ;This article is just a brain-dump of notes and links currently, here's some general info on the nodal model...
| |
| − | *The [[nodal network]] is formed from many [[peer]]'s each running the [[nodal reduction]] algorithm
| |
| − | *The nodal reduction operates on the local [[node space]] which is a collection of [[node]]s on top of a [[list space]].
| |
| − | *The currently running nodal [[peer]] version is [[peerd.c]]
| |
| − | *There are also incomplete versions in [[:category:peerd/files/PERL|PERL]] and [[:category:peerd/files/ActionScript|ActionScript]]
| |
| − | *See also [[:Category:Nodal Concepts]]
| |
| − | </table>
| |
| | | | |
| − | ==== Introduction ====
| + | In the [[nodal model]], the philosophy is used to [[unifications|unify]] the [[w:runtime|runtime environment]] with the [[w:class hierarchy|class hierarchy]] yielding a single global, [[self containment|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 [[node]]s called the [[nodal network]]. The nodes play a similar role to [[w:Object (computer science)|object]]s in the common [[w:object-oriented|Object-Oriented]] paradigm.<noinclude> |
| − | A [[nodal network]] is formed from many [[peer]]s each running the [[nodal reduction]] algorithm. Nodal reduction operates on the local [[node space]] which is a collection of [[node]]s on top of a [[list space]].
| |
| | | | |
| | + | Any object is related to other associated objects ([[association]]s a.k.a key-value pairs, attributes, properties, etc), which can represent active threads operating on a schedule. Active threads consume processing resources 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. |
| | | | |
| − | ;Node
| + | This functionality, which is common to all the objects of the [[nodal network]] is called the [[nodal reduction]] and is essentially a scheduler that replaces the traditional [[w:control flow|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 [[nodal reduction|nodally-reducible structure]] of [[node]]s, which means that any other application or organisation 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 a [[generic organisation]], which can be extended and refined for the needs of any context. |
| − | 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 [[identity|GUID]]s 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 [[w:runtime|runtime]].
| |
| | | | |
| − | Like a hash table, nodes are containers of keys and values, but because all runtime [[node references|node referencing]] is direct, the keys and values are references, not textual names like usual.
| + | == Summary == |
| | + | In the [[nodal model]], the items that make up the [[nodal network]] content are more similar to [[w:Object (computer science)|object]]s in the common [[w:object-oriented|OO]] paradigm than to files, because they exist and undergo change at [[w:runtime|runtime]] and exhibit persistent, globally unique [[identity|identities]] that are independent of their state or content. |
| | | | |
| | + | They are also more akin to objects because they take the form of a container of [[association]]s that are like an object's ''properties'' and ''methods'', and they define a [[w:runtime|runtime]] environment consisting of special properties like ''this'', ''name'', ''parent'', ''type'', etc, which are available within the context of any object's methods while they are executing. This allows the executing code to navigate and manipulate the object structure from the point of view of the executing method. |
| | | | |
| − | ;Nodal Network
| + | The main difference between a [[node]] and a traditional [[w:Object (computer science)|object]] is in the way the ''parent'' and ''class/type'' properties have been handled. In the nodal modal, the two form an axis with the current working context (usually the ''parent'') called ''down'' below, and the type/class aspect containing all the node's processes and knowledge above called ''up'' (these have also been called ''father'' above and ''mother'' below after the [[:Category:Philosophy|philosophical principles]] from which this [[dialectic]] method is derived). |
| − | The Nodal Network is formed from communications between all the [[Peer]]s. Each Peer applies the [[Nodal Reduction]] process to its local [[Nodal Space]], resulting in the organisation of globally unique nodes [[Identity|identities]] and the [[Storage and Distribution|propagation of change]] throughout the network. | |
| | | | |
| − | [[Storage and distribution]] is a [[:category:Nodal Organisations|nodal organisation]] which extends reduction out to form a single harmonic ''global reduction space'' called the [[nodal network]].
| + | In addition to this ''vertical'', hierarchical dimension formed from ''up'' and ''down'', there is also a ''horizontal'' dimension formed from ''left'' and ''right,'' which allows the description, navigation and manipulation of sequences of content or processes purely through nodal structure, which is geometric- rather than syntax-based. It means processes all have a common way of talking about order and time, and can be used to build the next layer of common functionality called "generic organisation". |
| | | | |
| − | 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]].
| + | == 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]]. |
| | | | |
| − | *DHT-like
| + | 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. |
| − | *Routing & Discovery methods
| |
| | | | |
| | + | [[List space]] provides a small set of functions which operate on a binary address space and offer a generic [[w:associative array|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. |
| | | | |
| − | ;Execution
| + | 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. |
| − | *Function bindings and references
| |
| − | *Nodes have a common method of describing the sequence and scheduling of processes
| |
| − | *Reduction
| |
| − | *Event model & schedule
| |
| | | | |
| − | ;Persistence | + | 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. |
| − | *Serialise & Deserialise
| |
| − | *Serialise builds a textual representation of a nodes structure, this is not an atomic process
| |
| | | | |
| − | ;Interface & Content
| + | == Abstraction layers == |
| − | *Renderable structure, including interface event represntation
| + | 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 [[w:runtime|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. |
| − | *Applicational 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]]. |
| | | | |
| | + | == 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 [[identity|GUID]]s 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 [[w:runtime|runtime]]. |
| | | | |
| | + | Like a hash table, nodes are containers of keys and values, but because all runtime [[node references|node referencing]] is direct, the keys and values are references, not textual names like usual. |
| | | | |
| − | | + | == Tree rewriting == |
| − | ----
| + | {{quote|It is perceived that one of the biggest problems in maintaining software quality is the above linear growth in complexity compared to the size of a program, resulting in the programmer's cognitive loss of an overview and ultimately the degradation of the quality of software. This thesis tries to counter that by introducing a language ([http://strlen.com/aardappel-language Aardeppel]) with a new sharing model that makes dependencies in a program explicit at the language level, and local to one specific language construct (the tree space). We introduce the language which is based on tree rewriting and Linda style tuple spaces and comes with a graphical programming notation. We discuss the worth of its design, precisely specify it using a formal semantics, and report on experience with the model using a real world implementation.|[[w:Wouter van Oortmerssen|Wouter van Oortmerssen]] (abstract from PHD thesis)}} |
| − | ''old intro text''
| + | [[Category:Nodal Concepts]][[Category:Legacy Projects]] |
| − | | + | </noinclude> |
| − | 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:
| |
| − | *[[Wikipedia:Mutex]]
| |
| − | *[[Wikipedia:Linearizability]]
| |
| − | *[[Wikipedia:Non-blocking synchronization]]
| |
| − | *[[Wikipedia:Lock-free and wait-free algorithms]] ''(a fragment extracted follows)''
| |
| − | :''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 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. [http://meta.wikimedia.org/wiki/Help:Edit_conflict 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
| |
| − | *[http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]
| |
| − | *[http://en.wikipedia.org/wiki/Prototype-based_programming Instance-Based Programming]
| |
| − | *[http://en.wikipedia.org/wiki/Self_programming_language Self Programming Language]
| |
| − | *[http://meta.wikimedia.org/wiki/Diff Diff]
| |
| − | | |
| − | #Nodal structure overview
| |
| − | In this project the network nodes are not files, but ''objects''. The whole network can be considered as one giant structure of persistent objects. In such an environment, there can be no ''static-inheritence-structure'' to compliment the ''runtime-object-structure'' as in most programming environments, because ''runtime'' is all there is! So a ''[http://en.wikipedia.org/wiki/Prototype-based_programming prototype-based]'' object-paradigm like that used by [http://en.wikipedia.org/wiki/ECMA-Script ECMA Script] has been adopted, where objects are "sub-classed" from other objects "in the field".
| |
| − | | |
| − | The terms ''class'' and ''instance'' can still apply, but in a prototype-based environment these terms represent ''relative relationships'' between nodes, rather than absolute information ''about'' a node.... ''old text regarding axes was removed from here --[[User:Nad|Nad]] 15:16, 20 Aug 2006 (NZST)'' the class and instance division of content is associations and current-loop, see [[Node]].
| |
| − | | |
| − | A major difference between working with prototypes rather than classes is that a class is completely static, it determines the types and names of all the methods and properties its instances will have throughout their entire lives. A prototype however, simply defines the contents of an object at the time of its ''instantiation''. But this initial content is not fixed, the set of available methods and properties changes with the time in the same way as a person performs different ''roles'' throughout time.
| |
| − | | |
| − | Another issue worth mentioning here is that we are using ''[http://en.wikipedia.org/wiki/Multiple_inheritance Multiple Inheritance]'' which has been a sensitive issue in programming for many years. Most of the problems with multiple inheritance are ultimately due to naming conflicts, which are irrelevent concerns in this model since nodes are referred to by their unique identifiers, not by their often ambiguous names.
| |
| − | | |
| − | Each node is like an ''[[Wikipedia:Associative array|associative array]]'' containing an arbitrary number of "named" references to other nodes. Of course the names are not ''ASCII'' as in normal associative arrays or objects, but Node references. ''parent-child-axis stuff was removed from here''. Parent-child (instance axis) is the tree of nodes formed by the current-[[loop]]s which undergo reduction (the ''now''), the class axis is the tree of all associations. --[[User:Nad|Nad]] 15:21, 20 Aug 2006 (NZST)
| |
| − | ----
| |
| − | | |
| − | | |
| − | #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...
| |
| − | *is a [[Wikipedia:Object Spaces|Distributed Object Space]] ''(a.k.a Tuple Space)''
| |
| − | *is a [[Wikipedia:Prototype-based programming|Prototype-based programming]] environment
| |
| − | *is an [[Wikipedia:Aspect-oriented programming|Aspect-oriented programming]] environment
| |
| − | *is a [[Wikipedia:Metaprogramming|Metaprogramming]] environment
| |
| − | *is an [[Wikipedia:Intentional Programming|Intentional Programming]] environment
| |
| − | *is an [[Wikipedia:Integrated development environment|Integrated development environment]]
| |
| − | *has [[Wikipedia:Reflection %28computer science%29|Reflection]]
| |
| − | *is a [[Wikipedia:Dynamic programming language|Dynamic programming language]]
| |
| − | *is an [[Wikipedia:Internet Operating Systems|Internet Operating System]]
| |
| − | | |
| − | #[[+The Nodal Model and OO]]
| |
| − | | |
| − | #[[+Gate Space]]
| |
| − | | |
| − | #List Space
| |
| − | The next level of the system is List Space. It is this layer which is used by nodes in Node-Space to undergo change and remember. List-space has only two functions:
| |
| − | * Getting and Setting (''get/set(ref,key0/1/2)'')
| |
| − | * Shifting Position (''traverse(ref,ref)'')
| |
| − | | |
| − | The space above this is Node-Space, which is similar in some ways to the doubly linked circular list (or '''loop''') data structure (see [[Wikipedia:Linked list|linked-list]]), which in turn some advantages and disadvantages over [[Wikipedia:Array|arrays]].
| |
| − | | |
| − | List-space offers only an associative ability (associate one thing with another thing). It's only called list space because its made from the same structure as linked lists and can support them all. Functions like reduction or traversing loops or linked lists ore actually done in Node-Space, which too uses associations, not list-item-keys like a linked list would.
| |
| − | | |
| − | | |
| − | ''NOTE: Actually there is one doubly-linked-list in list-space which is all the unused list-items. Get and Set also perform creation (by getting non-existent locations) and deletion (setting existing ones to root/zero/null), and this creation/deletion process involves unlinking and relinking items from the free-list. On initialisation of list-space all items form one long doubly linked list.''
| |
| − | | |
| − | | |
| − | '''Traversal:''' ''(a.k.a binary-traversal, list-space-traversal)''
| |
| − | *relative associations from interpreting binary-ref as key direction instructions
| |
| − | I was thinking that a good foundation for a lot of other discussion is the concept of ''binary'' in general. Binary is the simplest form of distinction, and the ''bit'' is the most fundamental unit of information. Binary and is not only made of two states, or symbols, but also gives rise to two different ''ways'' when considering ''sets'' of bits. These two basic ways are the root of the two domains.
| |
| − | *Names: The using of the binary sequence simply as being distinct from all other sequences. In the nodal model, traversal is used to assign distinct sequences to a particular piece of information.
| |
| − | *Number: A simple geometric which compliments traversal gives rise to ordered sequence, and using recursion is infinetly divisable. Ie a discrete process which forms a continuum. In the nodal model, the geometry is based on this method - recursively dividing a window or period.
| |
| − | | |
| − | | |
| − | #Node Space
| |
| − | | |
| − | ## Nodes & Associations
| |
| − | All of Node-space's functionality and structure is built from the ''associative-array''-like functionality provided by list-space's binary traversal mechanism. Node-spaces fundamental data-structure is the ''loop'', a kind of linked-list, but the links referred to are not list-item-references, but ''associations'',as defined by ''list-space-traversal''.
| |
| − | *here's some greek notes from the code comments regarding nodal structure:
| |
| − | *an association is a typed-relationship between its container and another node
| |
| − | ::''So there are three nodes involved here, the '''container''', the '''other''' and the '''type'''''
| |
| − | *each node contains only associations - it is a set of class:instance associations
| |
| − | ::''I've used the word '''set''' instead of list here, because its by traversal that you get to them, there's no full list of them''
| |
| − | ::''Although class:instance associations are analageous to key:value pairs in associative-arrays, they are not name-based, and you can't iterate through a list of them all''
| |
| − | *In each node, there are four fundamental associations, ''prev/next'' and ''parent/current''
| |
| − | ::''prev/next and parent/current (they can be called axes, horizontal and vertical)''
| |
| − | ::''These four are common to all because they are the concepts used by ''reduction'' which defines the fundamental functionality of node-space.''
| |
| − | *The prev/next associations form loops, and all the nodes in a loop are called siblings.
| |
| − | ::''The loops contain a subset of the nodes associations, and can be iterated through because they're linked lists''
| |
| − | ::''All the associations within a node are its '''potential'' content/structure, and those in the loop are '''actual'''''
| |
| − | *Nodal methods are ''create/delete/get/set'' association, and ''reduction''
| |
| − | | |
| − | | |
| − | ##Data-structure Loop
| |
| − | | |
| − | Each item in this linked-list is made of three item-references: a reference to the Previous item, the content itself (the "Middle"), and a reference to the Next item.
| |
| − | :''best to intro linked lists here really and in terms of nodes since not used in this way in list-space''
| |
| − | | |
| − | [[Image:data-structure.jpg]]
| |
| − | | |
| − | | |
| − | | |
| − | this is node space and forms doubly-linked-circular lists (loops) from next/prev ''associations'' (not list-space-keys)
| |
| − | | |
| − | Unlike <s>standard loops</s>doubly-linked-lists, every list-item in a loop is indistinct (apart from the current contents of its middle list-item-reference). Any item in the loop can serve as the current-access-point,i.e. a reference to a loop may change between different items in the loop throughout time.
| |
| − | | |
| − | This allows us to establish cycles, knowing where the current-access-points are going to be in the future allows a harmonicallly based data system based on cycles that may not yet be complete. This makes more common sense than most systems, being more like natural objects.
| |
| − | *In standard linked-list terms a loop is a doubly-linked-circular-list
| |
| − | | |
| − | | |
| − | ##Nodal Reduction
| |
| − | | |
| − | If each middle-key points to somewhere in another loop, we can see this loop as a torus (a tree of loops), or doughnut-shape, and each of the middle nodes can be a torus itself, so it is recursive, although at this basic level that isn't relevant.
| |
| − | | |
| − | Operating from the level above upon this list-arrangement in List-Space, is the generic process of reduction occuring in Node-Space, where after an operation is performed within a list-item, the torus shifts on its axis like a stepper motor and is ready to perform an operation on the next list-item.
| |
| − | | |
| − | Rotation and reduction are in the nodal-space level which is above list-space, and need know nothing about why what it did just worked.
| |
| − | | |
| − | Similarly, and one level up, an application or interface can manipulate what's in the loop, and therefore what gets executed and in what order and with what proportion of its resource, but the actual process of rotation and reduction is inherent in the data-structure, the application need know nothing about this level.
| |
| − | | |
| − | For a discussion on where this lowest-level process relates to the whole scheme of the project, see [[Nodal-space vs List-space]].
| |
| − | | |
| − | ; Some nodal-reduction code notes
| |
| − | *Reduction starts at root, every iteration of reduction involves one quanta being sent to root
| |
| − | ::''The root-node is also the first list-space item''
| |
| − | ::''root has an actual-loop just like all other nodes which rotates like normal each quanta''
| |
| − | ::''the root is all the high-level information and processes this peer supports or cares about''
| |
| − | ::''Like any other node, root contains potential-content, but in the special case of root, the potential content is every node this peer knows about. Also because its the root context, traversal is not necessary to reach those nodes - the direct reference, or address of the node is itself-within-the-context-of-root.''
| |
| − | *Quanta poor in a rotate withinwards as per the dynamic diagram that doesn't exist yet
| |
| − | *When a quantum reaches a node exhibiting a local declaration, it executes it and that iteration of reduction is finished
| |
| − | ::''As the quanta trickle down, rotation happens at every level regardless of whether or not execution occurred''
| |
| − | ::''Each quanta is really two, one for whole, one for part.''
| |
| − | ::''This is because when execution happens a second quantum is also sent to the class. This way all the non-actual associations in root also get quanta used for managing their many instances "in the field"''
| |
| − | | |
| − | | |
| − | ##Processing and Data Storage/Access
| |
| − | | |
| − | <s>Each "middle" list-item</s>The 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
| |
| − | *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. [http://meta.wikimedia.org/wiki/Help:Edit_conflict 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 [http://meta.wikimedia.org/wiki/Diff Diff]
| |
| − | #Schedule
| |
| − | The schedule is used at all layers; process execution, [[Schedule|application]], people and organisations. Here we discuss it in terms of the concepts and processes which make it up.
| |
| − | *[[Entropy & Potential]]
| |
| − | *Auto reduction
| |
| − | #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.
| |
| − | | |
| − | ----
| |
| − | | |
| − | <table><tr>
| |
| − | <td valign=top>[[Image:Nodal-scale.jpg]]
| |
| − | <td valign=top>[[Image:Nodal-potential.jpg]]
| |
| − | </table> | |
|
This page describes a concept which is part of our glossary
|
|
|
Legacy: This article describes a concept that has been superseded in the course of ongoing development on the Organic Design wiki. Please do not develop this any further or base work on this concept, now this page is for historic record only.
|
|
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 objects 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 resources 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 that 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 application or organisation 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 a generic organisation, which can be extended and refined for the needs of any context.
Summary
In the nodal model, the items that make up the nodal network content are more similar to objects in the common OO paradigm than to files, because they exist and undergo change at runtime and exhibit persistent, globally unique identities that are independent of their state or content.
They are also more akin to objects because they take the form of a container of associations that are like an object's properties and methods, and they define a runtime environment consisting of special properties like this, name, parent, type, etc, which are available within the context of any object's methods while they are executing. This allows the executing code to navigate and manipulate the object structure from the point of view of the executing method.
The main difference between a node and a traditional object is in the way the parent and class/type properties have been handled. In the nodal modal, the two form an axis with the current working context (usually the parent) called down below, and the type/class aspect containing all the node's processes and knowledge above called up (these have also been called father above and mother below after the philosophical principles from which this dialectic method is derived).
In addition to this vertical, hierarchical dimension formed from up and down, there is also a horizontal dimension formed from left and right, which allows the description, navigation and manipulation of sequences of content or processes purely through nodal structure, which is geometric- rather than syntax-based. It means processes all have a common way of talking about order and time, and can be used to build the next layer of common functionality called "generic organisation".
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.
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.
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.
Tree rewriting
 | It is perceived that one of the biggest problems in maintaining software quality is the above linear growth in complexity compared to the size of a program, resulting in the programmer's cognitive loss of an overview and ultimately the degradation of the quality of software. This thesis tries to counter that by introducing a language (Aardeppel) with a new sharing model that makes dependencies in a program explicit at the language level, and local to one specific language construct (the tree space). We introduce the language which is based on tree rewriting and Linda style tuple spaces and comes with a graphical programming notation. We discuss the worth of its design, precisely specify it using a formal semantics, and report on experience with the model using a real world implementation. |
— Wouter van Oortmerssen (abstract from PHD thesis)
|
