2014.11.21 Programmer's Notes

The tasks ahead are a pretty big list of big items, but it's fun for me to work on
this beastie of mine. :)

Next on my plate is migrating the 1.11 Java rule base to 2.0, and adding any customized
verbs to the 2.0 engine that I can't implement in 2.0 using GEL rules.  That will maximize
the number of function points that derive from the manufactured GEL code rather than
from hand-written code.  All of those function points in 1.11 are hand-written verbs, so
a lot of the modelled attributes aren't even accessible in the 1.11 rules, despite being
defined in the models.

That 2.0 rule base will initially target a CFLib/CFCore 1.11 code base, as do the 1.11 rules.
Once I'm at a testable clean build of the 2.1 code, I'll start the implementation of and
migration to CFLib/CFCore 2.1.

After migrating the code to CFLib/CFCore 2.1, I'll migrate the engine and CLI from 2.0 to 2.1,
and migrate the core any and java rules from 2.0 to 2.1.  This should be a relatively painless
rule migration, because it's the underpinnings of the code that will be changing, not the GEL
XML syntax.  i.e. The implementation is changing, not the interface.  Or at least not enough
to be significant (ICFLibAnyObj2 will become ICFLibAnyObj; I don't want to do that now because
it would break the 1.11 CFCore code by mandating a bunch of extra methods that I don't want
to implement in the 1.11 code base.)

I expect testing at this point to take a fair amount of time, because the structure of the
code is changing significantly, so I'm expecting bugs in the implementation.  Things *will*
be missed and broken along the way.  But in the end, I'll have 2.1 producing 2.2 code, which
should match the 2.1 code if the engine in CFCore has been successfully migrated.  One thing I'll
have to take care of along the way is adding Chain link establishment to the 2.1 manufactured RAM
persistence code that the engine runs on.  I want the core of the engine to be able to run
directly against models that are persisted in a database, not just loaded from text files.

Then comes the fun part -- a real 2.1 GUI, heavily customized from the code manufactured by 2.0.
I won't even *try* to migrate the 2.0 GUI rules to 2.1 until I've got a 2.1 GUI I'm happy with.
Among the features I intend to support with the GUI are proper logins/security through custom
code and messaging, import of text models (by redirecting the RAM backend to the appropriate
database engine, so there won't be *that* much code to implement for imports), and the ability
to export a model from the database.

Although I intend to allow the engine to run against the database directly in order to manufacture
code, the recommended mode of operation will be to use the GUI to edit the model in the database,
export it, and then run the 2.1 CLI against the exported model.  That way you can easily store
the model in a code repository as part of the "standard" work flow.

Once I've got the GUI implemented, I'll migrate the GUI rules from 2.0 to 2.1 so that it can
produce everything that 1.11 does, but on a 2.1 core and with a GUI for editing models.

That will leave me one more significant task to complete: the implementation of a JEE server
to receive and process the XML messages that are used internally by the existing GUI code,
and an appropriate client messaging implementation for the 2.1 GUI.  (I will not be allowing
the engine itself to run over the web.  At least I don't *think* I will.)

So that's 8 major phases to the 2.1 project.  Given that some of them will take months to
complete, I'd say 2.1 one won't be released for 1-2 years.  It'll keep me busy and out of
trouble for a while. :)