From OrganicDesign Wiki
Organic Design 2 | OD/Wikia | Wikia.php | Templates | Backup | Extensions
We've never been able to get the Organic Design wiki into an organised state, but I think the DPL extension can be the solution to this. We now have enough tools within the wiki environment to manage and organise all aspects of a simple organisation including accounts and scheduling - they just need to be glued together into a unified functional system.
Organic Design 2 is about creating a new structure from the ground up which encompasses all the organisational aspects we need, and does so in a re-usable way by creating it as a template-wiki. This article describes the proposed components of this template-wiki and their use, meaning and structure.
1 Extensions
We will include a standard set of extensions which reside on each server, but should be automatically syncronised to avoid manual work. The current list of proposed extensions to make available by default is:
2 Namespaces
All the content which is supplied as part of the template-wiki should be in a particular namespace, leaving the main namespace for the specific content of the wiki-instance. A namespace should be used when the article is of a particular class - ie it is used by the system itself and is expected to exhibit a specific format and content. If it isn't a class like that then it should be in the template or message namespace.
Here's the current list of proposed namespaces for the OD2:
- Transaction
- Account
- Group
- Event
- Resource
- Product
- Service
- Role
- Form
- Report
- Contact
- Message
- Log
- List
- Tree
- File
3 OD System
The current system should be modeled using templates and namespaces. Templates should be used rather than using parser-functions or semantic annotations directly so that they are methodology agnostic and more easily maintainable. The current general classes of job the OD system needs to model is:
- FS maintenance (wiki/web files, extensions, app versions, backups)
- Ontology maintenance (periodic scraping and querying - eg. source-code info, binary-info, media, viruses, prices...)
- Logs (rotation, aggregation and traffic/usage reports)
- Application installation, removal and upgrading
- Account reconciliation (both assisted and unassisted kinds)
- Tax forms and financial reports
- Servers and services/suppliers
- Clients/CRM
4 Semantic Rules
- Articles transclude high-level classes such as wiki or schedule
- These high-level types include rules which connect events to processes (this can include parameters such as a regexp)
- The parameters are constructed from the containing articles parameters with templates syntax like normal
- Kinds of articles which define rules use their own parameter content as parameters for their processes and events
5 Processes
- Processes are executed by information changing which is handled with the livelets extension
- Subscribers of change are processes (defined more statically in articles) and clients (defined dynamically by viewing articles)
- Processes should define entry and exit parameters (hash), implementation class, preferred implementation class, implementation instances
- Each implementation class should include: source (the installable/removable/upgradable of that environment), usage (execution method, protocols for entry and exit parameter hashes)
- Initial implementations: PHP, Shell (Perl, wget etc)
- The processes are queued when they are read by the livelets scheduler (either by perl rawly with expanded templates, or php when from server with qs arg)
6 Content
The basic organisational wiki requires many of the namespaces to exhibit pre-created articles which can be used directly or serve as templates to create variations from.
- Forms
- Reports
- Processes
- Templates
- Messages
- Logs
- Roles
- Lists
- Trees
- Files
7 Project Template
After creating a standard base template, the system should be extended to be able to create sub-templates. The first sub-template being a template-wiki for an instance of the project.
