It is amazing how a week old plan can become irrelevant.
Yep, you heard me right. I decided to ditch the plugin inventory -> DB concept, and will concentrate on in memory inventory handling.
First: It makes it much simpler for the programmer, in some aspects though.
Second: the plugin will have a smaller memory foot print.
Third: we do not need to ditch any of the first features planned for the inventory.
Fourth: in future build, we can always add the DB support.
How is the progress:
Well, not so bad. I had a skeleton code that I played with, and I had to do small tweaking in order for it to work in memory and not outside of plugin. The main GUI interface has been constructed, but do not think it is going to be sexy, it should be functional, intuitive and simple. I tested its main behavior and it seems to work/respond just fine.
Currently I'm working to re-design the Logic elements that has already been implemented into the plugin, so the designer may check Item state as easy as Dataref state. Unfortunately, when I first designed the Logic element, I did not design it to be flexible enough to incorporate other types of logic.
Here is an example:
Dataref logic - needs to test for Dataref value. The values we support are numbers so far.
Item logic - needs to test availability of item X in store Y and amount of Z. These are conditions that are not met in the Dataref Logic, and extending its design is a no no for me.
So now, I'm designing, piece by piece, the logic element, so I'll be able to add new type of logic, while the main Logic engine will handle it seamlessly.
I do not know how much time this will take me, but I put this into the "frustrating" category of feature adding and plugin designing.