Mike's Notes
Here are my rough ideas about how to create an environment in Pipi 9 for plug-ins.
I want to reduce Pipi to its essential and closed core, and the remainder will be turned into open-source plug-ins available on GitHub. The community could then create other plug-ins and modules to extend the platform.
I would like to talk with people who have done something similar.
Resources
References
Repository
- Home > Ajabbi Research > Library >
- Home > Handbook >
Last Updated
11/05/2025
Creating an environment for plug-ins
On a Sandy Beach: 04/03/2025
Mike is the inventor and architect of Pipi and the founder of Ajabbi.
From Wikipedia - "In computing, a plug-in (or plugin, add-in, addin, add-on, or addon) is a software component that extends the functionality of an existing software system without requiring the system to be re-built. A plug-in feature is one way that a system can be customizable.
Applications support plug-ins for a variety of reasons including:
- Enable third-party developers to extend an application
- Support easily adding new features
- Reduce the size of an application by not loading unused features
- Separate source code from an application because of incompatible software licenses
I have been putting off creating a plug-in environment for Pipi 9 because it wasn't an urgent task.
However, recently, a representative of a large software company contacted Ajabbi about embedding their product on ajabbi.com web pages, which raised the issue of plug-ins. We talked, and now they are considering it.
I might have a first plugin to build, so I better figure out how to do this. :)
I am now working this out by the seat of my pants, and things will no doubt change a lot.
I did a lot of investigating when working on Pipi 6 (2017-2019), and I liked how OpenERP (Now Odoo) enabled community-sourced extensions (they call them addons) to its open SaaS product.
- https://github.com/odoo/odoo/tree/18.0/addons/
- https://github.com/odoo/odoo/tree/18.0/addons/account
The Odoo addons are packaged using a sensible standard format.
- manifest_py
- readme
- controllers/
- data/
- demo/
- doc/
- i18n/
- models/
- report/
- security/
- static/
- tests/
- tools/
- views/
- wizard/
Plug-in package
A package structure similar to Odoo and simple industry standard file formats would work, packaged in a zip file and including the following.
- Name
- Description
- Author/developer
- Icon
- Manifest file (XML)
- Sample data (SQL)
- Language strings of any other language mapping to the base English string (CSV)
- etc
Plug-ins and modules are quite different.
SaaS Module
- SaaS applications are built out of reusable modules.
- The admin web UI should be the only thing required to add or remove modules (tick boxes).
- Modules follow domain-driven-design (DDD) principles.
- Have an MCV architecture.
- Examples:
- Assets
- Invoices
SaaS Simple Plug-in
- Simple Plug-ins add simple UI functionality to a SaaS application and usually involve HTML.
- Simple forms are used to add plug-ins.
- CMS Examples:
- Embed Google Map
- Embed ESRI Map
- Embed Mathematica Notebook
- Embed Jupyter Notebook
- Embed complex Java object
SaaS Complex Plug-in
- Complex Plug-ins can work with third-party applications using methods such as databases, APIs, scripting, XML, and JSON.
- The DevOps Engine (dvp) is required to configure integration.
- Examples:
- Office 365
- Google Workplace
- Zoho
- Odoo
Pipi Plug-in
- Pipi Plug-ins extend Pipi by adding 3rd-party software using wrapper and configuration settings.
- The DevOps Engine (dvp) is required to configure integration.
- The plug-ins can interact fully with the engines and other Pipi objects.
- Examples:
- Docker
- Database, e.g. semantic, graph, document
- Another computer language, e.g. Prolog
- Another API type, e.g. SOAP
- Azure platform config
- AWS platform config
- GCP platform config
- WolframAlpha
- ESRI ArcGIS
Engines
- The Plug-in Engine (plu) to register plug-ins is now being built.
- The Module Engine (mdl) registers all modules.
