|
|
| Line 12: |
Line 12: |
| | | | |
| | 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. | | 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 ==
| |
| − | {{Node summary}}
| |
| | | | |
| | == Abstraction layers == | | == Abstraction layers == |
| Line 21: |
Line 18: |
| | 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]]. | | 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,
| |
| − | :<tt>a = triangle.calculateArea(b,h)</tt>
| |
| − | 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:
| |
| − | :<tt>triangle.base = b</tt>
| |
| − | :<tt>triangle.height = h</tt>
| |
| − | :<tt>triangle.calculateArea</tt>
| |
| − | :<tt>a = triangle.area = b</tt>
| |
| − |
| |
| − | == Node space ==
| |
| − | A [[node space]] replaces both the [[w:control flow|program flow]] aspects as well as the storage and communications aspects of application architecture.
| |
| − |
| |
| − | ----
| |
| | == Node == | | == 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]]. | | 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. | | 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. |
| − |
| |
| − | == Nodal Network ==
| |
| − | 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.
| |
| − |
| |
| − | [[Communications]] is a [[:category:Nodal Organisations|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 == | | == Nodal Reduction == |
| | {{:Nodal Reduction/Summary}} | | {{:Nodal Reduction/Summary}} |
| − |
| |
| − | *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:
| |
| − | *[[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 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. [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]
| |
| − |
| |
| − | == 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]]
| |
| − |
| |
| − |
| |
| − | == 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
| |
| − | *[[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. [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>
| |
| − | [[Category:Nodal Concepts|Nodal Model]][[Category:Old Projects]]
| |
Summary
Nodal Model Summary
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.
Nodal Reduction
Nodal Reduction/Summary
