Tue, 04/28/2015 - 19:41
Dear Community,
At the moment OCCT OCAF persistence uses plugin mechanism, when library providing persistent functionality for particular subset of OCAF attributes is loaded dynamically at runtime by OCAF. For that, the plugin library name and location must be properly defined with help of predefined set of environment variables and resource files.
This system is quite complex and not transparent, especially for beginners.
We are going to simplify this to allow using normal linking mechanism instead of plugins, so that persistent library can be loaded by the application automatically at start-up.
It means that old plugin system will be removed, the resource files and environment variables will not be needed any more.
Instead it will be necessary to link to appropriate libraries providing persistence support and call some initialization function, directly from the application.
This modification does not suppose change of file format; API compatibility will be preserved except for initialization process.
In connection with this change, we would like to get feedback of the community.
If somebody has any argument for keeping plugin based persistence (as alternative approach, for example), share your point of view with us, please.
Best regards
FSR
Thu, 04/30/2015 - 15:24
Hello Forum Supervisor,
As of 6.8.0 which integrated the fix for #24925 (http://tracker.dev.opencascade.org/view.php?id=24925) this is likely far less of an issue. The users may now set up the mechanism using API, without env vars.
Apparently, some sort of plugins would still be required (so that the central OCAF mechanism could still load user-defined attributes), or you have to provide some API to register user-defined drivers in some global OCAF driver tables.
Very likely the upcoming change will not affect black belts who could master OCAF persistence in the past. They will be able to deal with the new mechanism. Hopefully white belts will be able to use new mechanism out of the box more smoothly.
My 2 cents.
Roman