Tonight, the Libraries of NIMH shall be constructed!

Well, I am certain at least one person apart from me knows about my project that is known as libNIMH. It has been something on my block for some time.

A brief description of what it is, would be all the base functionality of a typical modern program being put into a single set of libraries so as to not require me to have to constantly write what I am doing here.

• Socket handlers
• Threading abilities
• Dynamic Load (DL) plugin functionality
• Heap handling
• Stack
• Storage abilities
• State storing/autosave
• Configuration, via command line and save file with the ability to commit save information
• Embedded scripting abilities (via Lua5, Ruby, Spidermonkey, v8, Perl5, Python2, Parrot, SMsSys, Mono and JVM)
• Secure Socket Layers (socket encryption as the default)

These days, I am finding I am doing a lot of my programs have sockets, threading, storage, configuration options and some scripting. I am adding Heap/Stack and dynamic loading options as these are generally very decent things to add. Dynamic Loading will generally work for what I want to do, which is allow for modules to be loaded and unload on the fly, without starting or stopping the programs. To slim down memory usage of a program, or add functionality needed (and perhaps unload the module if hard drive lag does not offset RAM conditions).

You will note that for the embedded scripting there is a large amount of options present. Though, these would be loaded and unloaded entirely via the DL section of libNIMH. So to try to remove some bloat.

I will be calling each program using libNIMH that is currently open a "book". Programs are the software using libNIMH--but each running process using libNIMH will be a book.

I am also debating on some form of signal system for libNIMH type programs. The issue is that libNIMH likely will not have a set port open to it, and the system will likely have several libNIMH books open at once. I could have a main libNIMH scoreboard file with libNIMH signal ports listed in it. The communication ports will likely be whatever random ports that those particular libNIMH books can acquire above 1024.

I am looking at figuring out the protocol used for interprocess communications along ::1 (aka 127.0.0.1) to use UDP. Trying to keep the confirmation speed going quick enough that interception should be hard to set up. On comparison to an encrypted communication on ::1, which if you can intercept UDP going to ::1 on a system, you can easily man in the middle an SSL connection on ::1.

Out side processes can ask what libNIMH ports are open, allowing a single port to be given out, to allow easier knowledge of what is on a system to be given out. As an alternative to being port scanned (though port scans would still likely occur).