Technologies

Some software engineers have expressed interest in what methodology I use to do Neurospaces development. Right now, I only reuse many common patterns, present in various frameworks (e.g. Spring and aspect oriented programming). For the rest I don't use a fancy framework, because computational neuroscience simulator technology is not yet ready for it. The Neurospaces project is a search for such a framework.

Comparing for a moment to the aforementioned Spring framework, the following tools are present, in one form or another, in the current incarnation of the Neurospaces project:

• Inversion of Control container: the Simple Scheduler in Perl does a couple of things for dependency injection, much work remains to be done, if it is ever needed.
• For low-level code, I have written a C code generator that allows for inheritance and highly-granular method instrumentation, a first step towards AOP. Aspect-oriented programming framework: aspect oriented programming is supported natively by scripting languages as perl.
• Data access framework: the project browser relies on Sesa, and can, in principle, be bound to external data access frameworks. Again, if this is ever going to be necessary remains to be seen (for web-collaboration sessions ?).
• Transaction management framework: not present (for simulations, this not needed in the short term either).
• Model-view-controller framework: the split of the simulator in middle-ware for the data container, the solvers, and the scheduler, is partially based on the model-view-controller paradigm.
• Remote Access framework: not present, although needed, in principle, that is.
• Authentication and authorization framework: the Sesa framework provides this, in a 'primitive and premature' fashion.
• Remote Management framework: not present, unsure if that is needed.
• Messaging framework: not present, way to early to even think about it.
• Testing framework: the tools in the neurospaces project use a sophisticated tester, that implements a clear-cut separation between test specification (application behaviour) and test implementation. Changing the implementation allows to convert the test specifications to HTML, or to extract certain data from the specification (e.g. show me a test that uses command 'X').

For component integration, I use:

• Swig to expose low level functionality of components, fi. Heccer or Neurospaces, to higher level programming languages and scripting languages.
• the Perl programming language, because (1) I am very familiar with the internals of Perl, and (2) there is a very broad library of Perl modules available from CPAN. Some people tell me that I should be using Python, for easy interfacing with PyNN (and they are right about it, but I don't know much Python).