Gfursin at 08:33, 23 October 2013

2013-10-23T08:33:35Z

Gfursin at 08:31, 23 October 2013

2013-10-23T08:31:18Z

Gfursin: Created page with "== Disclaimer == The alpha variant of this document has been written by Grigori Fursin very quickly during development of the cM framework. Specification may still be changin..."

2013-10-23T08:28:39Z

Created page with "== Disclaimer == The alpha variant of this document has been written by Grigori Fursin very quickly during development of the cM framework. Specification may still be changin..."

Show changes

@@ Line 55: / Line 55: @@
                            /php/module.php
-== Implementation and compatibility ==
+<h2> Implementation and compatibility </h2>
+<p><img _fck_mw_valid="false" _fck_mw_filename="Fig cm internals brief1.png" alt="" class="fck_mw_notfound" />
-[[Image:fig_cm_internals_brief1.png]]
+</p><p>We envision that cM framework will constantly evolve, hence we decided to implement all cM logic (kernel, access to repository, web server, visualization, predictive modeling, security, etc) as modules inside cM repository. Instead of providing versions of the framework and all modules, we use module UID as a version number. If the module evolves with backwards compatible API, neither alias nor UID is changing. However, if API or associated data becomes backwards incompatible, a new module should be created with a new UID while alias may remain unless the meaning changed. Internally, modules should call other modules only through UID and not through alias to solve compatibility issues: multiple versions of the module can co-exist, but other modules should be explicitly upgraded to support new modules. This also solves data compatibility - we do not allow to mix up data from incompatible versions of a module.
+</p><p>TBD: Version and build number of a module can be provided to keep track of changes.
-We envision that cM framework will constantly evolve, hence we decided to implement all cM logic (kernel, access to repository, web server, visualization, predictive modeling, security, etc) as modules inside cM repository. Instead of providing versions of the framework and all modules, we use module UID as a version number. If the module evolves with backwards compatible API, neither alias nor UID is changing. However, if API or associated data becomes backwards incompatible, a new module should be created with a new UID while alias may remain unless the meaning changed. Internally, modules should call other modules only through UID and not through alias to solve compatibility issues: multiple versions of the module can co-exist, but other modules should be explicitly upgraded to support new modules. This also solves data compatibility - we do not allow to mix up data from incompatible versions of a module.
+</p>
-−
 TBD: Version and build number of a module can be provided to keep track of changes.
 == Single access function ==

Tools:CM:Specification:V1.0 - Revision history

Gfursin at 08:33, 23 October 2013

Gfursin at 08:31, 23 October 2013

Gfursin: Created page with "== Disclaimer == The alpha variant of this document has been written by Grigori Fursin very quickly during development of the cM framework. Specification may still be changin..."