Monday, 21 June 2010

Details and Features

I've expanded a bit on the higher-level goals, now I'll describe how I see it working and some of the features it must have.
The core of it will be a system of virtual circuit elements, or virtual components, connected together via their virtual I/O pins. There will be fundamental component types (that get implemented in code) and composite components built up from these fundamentals (and indeed other composite components). (Aside: The word virtual which applies to most of these concepts, since they mimic real-world electronic circuits, will get a bit tiresome quickly so it will be assumed henceforth.) Input and output to/from the computer running the system will just be implemented as a set of components and wired up as signal sources and sinks. These circuits will run on one or more connected computers, with interconnections abstracted away as much as possible, allowing seamless wiring across machines. It will be edited via the network connection from an editor running on another computer. This editor will employ sophisticated visualisation techniques to make navigation around complex circuits and systems easy, providing rapid editing, tweaking, and viewing of the circuits as they are running.

The hosting service must be able to run on a variety of hardware from old salvaged 386's up to modern high end multiprocessor machines. This is important as I want to be able to utilise the cheapest and simplest hardware to solve a given problem, or conversely just use whatever is to hand to solve the simplest problem.

The overall systems you would be able to create with this tool could be as large as spanning many dedicated machines across a network or the Internet to just a single background task on a single machine. Being able to distribute work and scale systems as easily as dragging a circuit from one box to another and have it all just work is vital for supporting high bandwidth compute bound processing systems (e.g. computer vision) as well as physically distributed systems (e.g. large plant control or multi site monitoring).

Some of the other features I envisage are as follows:
* Libraries of common components.
* Multicore wires (simplifies connection diagrams).
* Wiring conduits (control inter-process/network communications priorities).
* Buses (higher level distribution and aggregation points).
* Diagnostics components (editor only control and monitoring).
* Arrayed connections (for lists and collections of signals).
* Arrayed components (for iteration on a collection of signals).
* Control wiring (signals, think: pass by value).
* Process wiring (objects, think: pass by reference).
* ...

I will go into more detail on these at random in future posts.


  1. So far, I think I'm understanding most of what you are saying. This is a better overview than what you've done face to face, I think because in conversation you get excited about everything and so talk about everything at once.

    From the list above, what I understand the least (and thus would most like expanded on) is (in order of least understood to most understood):
    - Buses
    - Multicore wires
    - Wiring conduits
    - Arrayed connections/components
    - Control/Process wiring


  2. That gives me some topics for my next few posts then. Excellent.