Hivemind (again!)
Reading through the documentation that talks about “Configuration Points” I’m struck that there’s a definite missing piece in the puzzle. When I am faced with a brand new piece of software the first thing I do is scan through all the menu items and toolbar buttons that it has. The next thing is to open its options / configuration dialog and scan through and see what is configurable about it. Just doing these two things tells me an awful lot about the piece of software in question. Virtually every piece of software I have encountered allowed some sort of runtime configuration that was persisted in some manner, whether that be in a database or in a file or what have you. While Hivemind is great about reading in the static data that will configure the various services within the application, it doesnt appear to have a clue about runtime, modifiable, persistent configuration. I ran into this a long while ago when writing a Prolog application, wanting to modify the internal decision making tree in the core of the app: it locked me out, wouldnt let me, telling me that the data was read-only. The sense of frustration ran as high then as it does now.
It doesnt seem like there’s a big leap to specify a for an application, with associated , that will be used dynamically to load and save the runtime modifiable options. Hivemind does claim to make life easier yet this oversight seems to let it down.
Open Source programmers generally write code to “scratch an itch” so does this constitute an itch that I should scratch, by writing the code the way I want it to work, and submitting it back to the Hivemind project to use?