[yocto] Need for offline binary configuration

[Venkata ramana gollamudi]

Added few more thoughts
Looking for possible options to implement Offline Configuration Tool requirement. please check and comment on it.

Configuration flow:

a) Task do_createconfig will generate data to configure. This serves as input for configuration UI in OCT.

b) OCT UI will read that config data(from step(a)) to show it in GUI. User configures using GUI inputs. Stores the user OCT configuration to OCT config file. (Note user can directly modify the OCT config file, if User is familier with it)

c) preinst, postinst, prerm, postrm, or a do_applyconfig(without bb files reparse), can read OCT config file content (using a library) and apply necessary changes.

Now we can look into possibility of using a specific configuration UI implementation or a generic configuration model or combination of both.

1) Using a specific configuration GUI implementation:
   do_createconfig generates the configuration information, in format like datafile/xml and OCT reads this config data and provides a GUI to modify or configure the features.

Pros: Detailed and complex GUIs can be supported which will be user friendly. Ex: User management, network management etc.
Cons: As UI is static, it has to be modified to support new configuration requirements
and UI modifications are generally complex.

2) A generic configuration model
   do_createconfig generates configuration information with presentation information included (like kconfig) and OCT reads this config information and provides a generic UI implementation to modify or config the data like menuconfig.

Pros: 
	- Generic and dynamic UI allowing the config menus to be added from poky layers providing platform for configuration.
	- New features can add new menus configuration options. Feature/package enable and disable can control the configurtion menus. 
	- So configuration is shown only if feature/package is present/selected.
Cons: 
	- Generic method of implementing can be complex, specifically for features where configuration is complex ex: User management, network configuration.
	- Custom or specific UI will be more user friendly and gives more control to UI designer.

3) Combination of both
Complex features requiring more UI control can implement those features using the method(1) and also providing the plaform for generic UI implementation.
OCT displays both UI configurations.
Ex: Static Image level features like User management, network config can be implemented using method(1) 
    Service configuration, file system type, hist size configure etc can be implemented using method(2).

Pros: Gives control to project to select the Complex and simple UIs.
      
Cons: Still needs a OCT UI change if method(1) feature need to be changed.
      Drawing a line between complex and simple UI features may not very straight forward.
      Adding dynamic Complex UI is not possible to be added from poky layers.

Decision to provide a generic configuration model is mainly based on how much we expect the configuration area to grow along with layers.
Image level features like user management, network management generally are not dynamic features, so having a specific/custom UI implementation looks fine for such features.

Regards,
Ramana