more on “daemonic” programming
In the last post I alluded to trying to use a reactional programming model for distributed programs. Since it mimics network deamons – we call it demonic programming. (once thought about calling it project 666 – but not in the baptist south).
There are some security issues with such an approach, but they can be managed.
In addition to secure implementation of the deamon itself (i.e. it needs to be effectively sandboxed and not crash ungracefully) there are basically two features that ensure secure behavior.
- The XML document describes what the calculation does, but does not allow programming of the application. To put it simply the document can say add two numbers, but does not define what addition is.
- The deamon is stateless. No information is saved from invocation to invocation. In this sense, it is a purely functional approach. We’re used to this in the HTML world – Apache is a stateless program because requests arrive in arbitrary order and must be processed as they arrive. (when they are stateful – for example wordpress which is being used for this blog – the statefullness is via other parts of the code, like the database engine, and is always a potential security hole. It would be easier to break wordpress than apache).
The system is then programmable in that it selects from a menu of defined (nominally secure) functions in some sequence. The sequence is controlled by the document, and more interestingly by the ability of the functions to proceed. So if events a,b,c are independent of each other, but even d requires the outputs of a & c, then a,b,c can occur in any order, but d must wait for a & c.
There are some other issues involving what happens if you allow jobs to spawn multiple ones, and what happens if processors die, but I think it may be time to run a simulation.