|
|
| Our terminology:
|
|
|
| -*Package - the largest grain of our modular arcthitecture, it is a intended to be a large feature scope - such as the WikiPackage or BlogsPackage. The term Package was introduced as a concept in TikiWiki by Dennis Hetzel.
|
| +*Package - the largest grain of our modular architecture, it is a intended to be a large feature scope - such as the WikiPackage or BlogsPackage. The term Package was introduced as a concept in ((TikiWiki)) by Dennis Hetzel. |
| *Modules - we have maintained the "Modules" term to be identical to the TikiWiki usage. Modules are the "blocks" (in *nuke terms) of data that appear on the sides of the page - such as "Last changes" or "Last blog posts"
|
| *Plugins - Packages can contain plugins inside them to enable modular functionality. The LibertyPackage and WikiPackage both have their own plugin architecture to handle different data.
|
|
|
| -These feature sets are known as a bitweaverPackage. The primary goal for bitweaver was to place the __fewest possible requirements__ possible on a bitweaverPackage and provide the most flexible enviornment possible.
|
| +These feature sets are known as a bitweaverPackage. The primary goal for bitweaver was to place the __fewest possible requirements__ possible on a bitweaverPackage and provide the most flexible environment possible. |
|
|
| This diagram uses a powertool metaphor to illustrate the functional inter-relationships of our packages:
|
|
|
| {attachment id=125}
|
|
|
| -There is a KernelPackage that provides a core set of functionality that provide global services (such as preferences, user authentication, themes, permisions and such).
|
| +There is a KernelPackage that provides a core set of functionality that provide global services (such as preferences, user authentication, themes, permission and such). |
|
|
| {toc} |