Excerpts from earlier brainstorming notes that are still relevant

For more information on SMN see SMN on Anandavala.

In the matrix/vector view the designer can click on any matrix or vector element or any matrix row to receive a dialogue presenting a range of ways that they can interact with that element. E.g. Change an SVElement's data value or define a rowOp or select a pre-made virtual system from a palette and deploy that within the model.

There is a palette on the side of the interface – when you click on an SVElement the palette displays the list of all known components that can usefully go into this element. When selecting a row it shows all the predefined rowOps. If some element is already selected the designer can click onto the object within the palette to insert it into the element. There will be some means of selecting multiple elements and then clicking on a palette object.

When the object is inserted into the element the designer can click on the object to set its properties and attributes. There is some means to select and deselect systems for viewing. The matrix and vector adapt accordingly with rows and columns appearing or disappearing. This gives control over what is shown in the limited viewing space of the matrix/vector view. For a large model you couldn't fit it all comfortably into a web browser window and having to scroll over the whole flat model would be cumbersome and disorienting. Instead have it so that the view registers with various systems and synchronises with their state. Only when registered is there a row/column and vector element for this system.

These viewer-objects (row/col/svElem) can be arranged in any manner that suits the designer – they can be moved around easily – just right-click on a view-object (i.e. element, row or column) and then click “move to” and then click the view object that is in the destination location and the selected view-object is inserted in the destination location. The other view-objects adjust around it. In this way the designer has a controllable view into the model through which they can edit the model.

As described so far it has no allowance for coding of new systems but only the reuse and re-configuration of pre-made sub-systems presented in a context sensitive palette for insertion into the model and then customisation. If the application is developed as an IDE plugin (e.g. Eclipse, Netbeans, etc) then the IDE allows the designer to code the atomic systems in various programming languages and the SMN plugin can incorporate these into its system palette.

We start with very simple systems and using these we build more complex systems, which are then added to the palette. Then from these we make even more complex systems and so on.

If the palette can draw on any web repository of SMN systems then the range of available sub-systems can grow rapidly through collective development. www.Anandavala.info can provide an initial open virtual space and open system repository. People can create and play with systems in the open virtual space and they can save their creations to the repository so that other people can reuse them. This could become an open-system development community (rather than open-source).

In general a vSystem cannot directly influence the state of another vSystem, they can only influence each other through the system logic – however, using wrappers in a pure virtual context a vSystem can use a wrapper to represent itself differently. A pure vSystem's state can only change through the system logic, but a wrappers state can also be externally influenced – this is the core difference.

The object model is produced by distilling out the whole of SMN and leave behind only the abstract system – this is what is stored and operated on as the model – only for visualisation and so on will it be cast into an SMN like form. So each 'system' entity class contains the state data (SVElement) and the output interface (SMCol). The input interface and the sub/super class/system relations are all separate metadata that can be merged with the system to cast it into an SMN like form – this is a flow model where each system experiences the flow of information from the common SV data space. Each system can only control its own state, and external clients interact with the virtual systems by influencing the state of wrapper systems. The influence that the system wields in the virtual space arises due to other systems observing its state data and responding.

This system object-model can be distilled from the SMN model and it makes the interaction channels between systems direct. Rather than SMElement data being mediated via the SMN algorithm there are direct references between Java objects.

SMN takes the REST principle all the way! Below is a quote from Building Web Services the REST Way (http://www.xfront.com/REST-Web-Services.html):

“Here are the characteristics of REST:

• Client-Server: a pull-based interaction style: consuming components pull representations.

• Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.

• Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.

• Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).

• Named resources - the system is comprised of resources which are named using a URL.

• Interconnected resource representations - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.

• Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

”

Each vSystem is a client and the server is the network of vSystems, the collective. Each client has a particular connection from the server (input interface) through which it receives data and a particular connection to the server (SVElement) through its data flows on to others. Each SVElement is read-only to all systems but the associated system, so it can only influence the collective by changing its state in the SVELement. An SVElement is a piece of state data that represents some systems state within the virtual space – the system that is represented may be a vSystem or a physical system (I.e. A wrapper) – so long as it can synchronise some of its state with the SVElement.

Each system only has access to the information flowing in through its input interface and cannot use any other state, hence the systems are stateless.

Some states are static and can be cached – is this effectively implemented by energy flow?

The uniform interface is SMN itself, which provides a unified mathematical framework.

All systems have URIs.

SMN excels at representing interconnected resources.

Layered components can be inserted into the modular process.

Input not fundamental to EFSMN – output is.

If a system object only had its input interface explicitly defined, then it has references to other systems from which it draws data and then uses this to change its own state – but what then? There is no EF process to recognise which systems depend on this state and need to be reprocessed. Hence each system needs to have an output interface, which sends a signal down each output channel to wake the dependent system up so that it can process its inputs then change state then wake up downstream systems and so on... So its a receive then nudge approach. Receive all required data, change state then nudge any systems that are registered as observing that state. Systems can register with other systems to be notified of changes of state – they are then placed in that systems output interface and they place that system in their own input interface.

In the object model, once a system has received some new data due to a state change followed by a change notification, the system either (case A) pulls the other state data that it needs via its input interface, or (case B) if no change notice is received the state stays as before so no data is pulled. The system then changes state, then sends its new state to all systems in its output interface. With case B this is a push only model where system states are cached by each system and only change due to a change notification. Case B is good for systems that are remote – in distant servers – and case A works best for systems in the same memory space. Hence there is a distinction between local and remote systems that parallels un-cachable and cachable.

The object model represents the pure connectivity between systems whereas the SMN model also stores things such as matrix or vector indexes which are really SMN specific. The pure connectivity is the actual model and SMN is just a useful view on it. SMN is a view through which systems can be comprehended via a compact matrix interface. The actual model has no view specific data of any kind. Each vSystem can be identified by a URI like a standard REST system.

The SMN view can read in interconnected networks and present them in a matrix or network view, making it available for simulation and testing – that is the main role of the SMN application – as a view! That means that the core is more general. The core is a network of objects within some computational space, whether Java objects or C objects or whatever – the actual model is the pattern of connectivity – they could be documents or OWL classes or whatever but they have some pattern of connectivity. SMN is a view that can operate on the pattern regardless of what the data is! That is a computer.

XML can represent the pure pattern and this can be unserialised into any kind of instantiated object. Meanwhile SMN can read and write XML, visualise the pattern and provide design access to the pattern and the data embedded in it. The actual instantiation or unserialisation of any objects is done is some computational space such as a Java virtual machine. Lets call this computational space the instantiator. SMN only operates on the pattern of data, it is up to the instantiator to actually instantiate the objects. In this sense SMN is like a general IDE for any network of systems. It allows one to create or analyse complex networks of any kind – it allows one to work on the network structure – the pattern itself – separate from the actual objects that comprise the pattern.

A new method of software development could be to build abstract system models in SMN and produce XML specifications of whole programs or modules. Then in any computational environment such as Java one can unserialise the XML and produce actual Java objects that represent the full object model defined in the XML specification. This object model functions as the model system – I.e. The software product. Hence it was designed as an abstract model, stored as XML and then instantiated into any XML-to-object enabled computational space.

I could create virtual web services as XML models then instantiate them within JSP and PHP pages to implement the web service. I could also create simple programs and then instantiate them in various OO environments such as Java and C . They would be identical systems with identical specifications but operating within different computational environments.