Following the advices of "The art of Unix programming", splitting cme and Config::Model in several co-processes may help people understand what's going on under the hoods:
the communication between processes is done with a text protocol (needs to be bi-directional)
the GUI is done first
Each backend can have its own process
The design of Config::Model is already done in 3 main parts:
The UI (graphical or not)
the core (the configuration tree)
the read/write backend
Currently these 3 parts run withing a monolithic process using an API which is not too complex so splitting there should not be too difficult.
The protocol between the process must have instruction to get and set values but also to queries the configuration tree for:
online help
element list
list or hash indexes
element info (type, value type and other parts from the model)
Following the advices of "The art of Unix programming", splitting cme and Config::Model in several co-processes may help people understand what's going on under the hoods:
The design of Config::Model is already done in 3 main parts:
Currently these 3 parts run withing a monolithic process using an API which is not too complex so splitting there should not be too difficult.
The protocol between the process must have instruction to get and set values but also to queries the configuration tree for:
I'll refine this bug further as the idea matures