Showing posts with label plugin. Show all posts
Showing posts with label plugin. Show all posts

Creating 18 Engine descriptions

Mike's Notes

18 working engines are currently being imported into Pipi Core, configured, and tested.

Alex has sent me a DeepSeek chat that generated descriptions of those engines and how they worked together by analysing the existing web page "20 Engines". DeepSeek also produced a Mermaid Diagram from Markdown code based on those descriptions. DeepSeek was partially correct in some descriptions.

The Mermaid diagram was wrong, but what a great tool for Pipi to self-document with CL and accurate Markdown descriptions. It will be widely used in future as a plugin.

Feedback and suggestions are very welcome as always.

Update 23/05/2026

Java and CGI Engines added for interoperability by Pipi.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

23/05/2026

Creating 18 20 Engine descriptions

By: Mike Peters
On a Sandy Beach: 06/05/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Most Pipi engines have historically been poorly described. This is an attempt to write better descriptions for the 18 20 engines currently being imported.  I had a go, then used Gemini to come up with better wording, then Mrs Grammarly did her bit. 😎

Much later, once the workspace UI are working, a one-page summary about each engine can be written for the pipiWiki. The Wiki Engine (wik) in the resources above has an example of such a summary.

Note: These are listed in the order they are being imported.

Descriptions

Each engine has;

  • Unique Name (Unique 3-letter code)
  • S: Short description suitable for tooltips under 100 characters.
  • D: Description under 255 characters.

System Engine (sys)

  • S: System identity and lifecycle controller.
  • D: Manages the vital signs and lifecycle of Pipi’s dynamic engine ecosystem, fostering complex emergent behaviours through seamless interaction.

Nest Engine (nst)

  • S: Host and environment interface bridge.
  • D: Serves as the foundational gateway between the host OS, JVM, the application server, CGI, and the internal Pipi environment.

JVM Engine (jvm)

  • S: JVM interoperability.
  • D: Provides Pipi with a way to work directly with an external JVM.

CGI Engine (cgi)

  • S: CGI interoperability.
  • D: Provides Pipi with a way to work directly with external CGI.

Namespace Engine (nsp)

  • S: Global identification and addressing.
  • D: Enforces a conflict-free global naming convention, ensuring every system element is uniquely addressable across the entire platform.

Render Engine (rnd)

  • S: Static file and asset rendering.
  • D: Processes and renders static resources, including HTML, CSS, source code, and databases.

Template Engine (tem)

  • S: Reusable pattern templates.
  • D: Manages reusable structural pattern templates used by the CMS to generate database-driven pages and components.

Variables Engine (var)

  • S: Centralised variables library.
  • D: Provides a centralised repository for managing variables used across templates, system configurations, and executable logic.

Log Engine (log)

  • S: Universal logging and telemetry controller.
  • D: Aggregates and configures logging parameters across all active engines to provide system-wide transparency and diagnostics.

Data Engine (dta)

  • S: Database lifecycle and CRUD operations.
  • D: Generates SQL to command the creation, evolution, and deletion of databases and their underlying data objects with full administrative control.

Configuration Engine (cnf)

  • S: Engine blueprint and manufacturing settings.
  • D: Supplies the precise DNA and configuration parameters required for the automated fabrication of individual Pipi engines.

Versioning Engine (ver)

  • S: Semantic versioning and update tracker.
  • D: Maintains system integrity by aggregating incremental updates from all engines into a unified semantic versioning timeline.

Code Engine (cde)

  • S: Internal code generation.
  • D: Facilitates automated code generation, including class libraries and logic synthesis directly within the Pipi platform.

Conductor Engine (cnd)

  • S: Internal process regulator.
  • D: Operates as the high-level orchestrator for major internal system processes and synchronisation.

Directory Engine (dir)

  • S: CMS file system and path manager.
  • D: Manages the logical and physical file system directories generated and utilised by the CMS.

Node Engine (nde)

  • S: Hierarchical template tree architect.
  • D: Maintains the addressable tree structure of templates to define content hierarchy within the CMS.

CMS Engine (cms)

  • S: Digital content management.
  • D: Powers the end-to-end lifecycle of digital content, from initial creation and editing to final publishing.

Core Engine (cor)

  • S: Primary system driver and logic hub.
  • D: The central engine that powers fundamental system behaviours and executes the primary logic that keeps Pipi running.

Factory Engine (fac)

  • S: Automated engine fabrication.
  • D: Assembles and deploys engines based on stored configuration files and real-time updates.

Page Engine (pge)

  • S: Semantic relationship and metadata mapper.
  • D: Maps external relationships for pages, managing keywords, references, and "See Also" semantic connections.

Continental Drift

Mike's Notes

This is an example of a Notebook from Observable embedded on this page using an iFrame.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Observable Newsletter
  • Home > Handbook > 

Last Updated

26/03/2026

Continental Drift

By: Nicolas Lambert
Observable: 02/2026

Hi. I'm Nicolas Lambert, research engineer in geographic information science at CNRS (France). My job is to draw maps and teach cartography at the university. I am a geographer 🌎, and not really a developer 🖥️.

This notebook compresses 750 million years of continental drift in a mesmerizing animation. It includes current country boundaries, so as the animation loops, you can follow how different regions emerged over time.

A Critique of Iceberg REST Catalog: A Classic Case of Why Semantic Spec Fails

Mike's Notes

I like the specification and hope to enable its use via a future Pipi plugin. Here is an article by Ananth Packkildurai about some flaws that need fixing. His weekly newsletter is worth subscribing to.

Resources

References

  • Iceberg REST Catalog Specification.
  • Designing Data-Intensive Applications, by Martin Kleppmann.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Data Engineering Weekly
  • Home > Handbook > 

Last Updated

19/01/2026

A Critique of Iceberg REST Catalog: A Classic Case of Why Semantic Spec Fails

By: Ananth Packkildurai
Data Engineering Weekly: 9/01/2026

Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing insights on modern data platforms, large-scale pipelines, and AI-driven architectures..

How a Semantically Correct API Becomes Operationally Unreliable at Scale.

“Latency is not just a performance characteristic; it is a fundamental part of correctness.” — Designing Data-Intensive Applications

In Designing Data-Intensive Applications, Martin Kleppmann makes a subtle but critical point: the CAP theorem omits latency, yet in real systems, latency often determines whether a system is usable at all. A system that is correct but slow is, in practice, incorrect.

This observation is directly applicable to the Apache Iceberg REST Catalog specification. While the specification achieves semantic clarity, it fails to define the operational realities that enable distributed systems to remain predictable at scale. The result is a standard that is formally correct, yet operationally fragile.

Semantic Interoperability Without Predictability

Over the past two years, the Iceberg REST Catalog specification has emerged as the de facto standard for metadata access in the Iceberg ecosystem. We have seen the outburst of the catalog war around the REST spec. It promises a universal interface that allows engines such as Trino, Spark, Flink, and StarRocks to interact with Iceberg tables via a common REST abstraction, independent of the underlying catalog implementation.

At the semantic level, this promise largely holds. The specification rigorously defines metadata structures: tables, schemas, snapshots, and namespace operations. A LoadTable or CreateNamespace request looks identical across implementations. This semantic interoperability has been critical to Iceberg’s rapid ecosystem adoption.

However, semantic interoperability alone is insufficient. The specification defines what metadata operations mean, but it avoids specifying how they must behave in real-world conditions, such as concurrency, latency sensitivity, and cross-catalog synchronization.

This gap—between semantic interoperability and operational interoperability—is where systems begin to fail in production.

The Core Problem: No Operational SLA, No Predictability

The Iceberg REST Catalog specification is intentionally silent on performance guarantees. There are no latency expectations, no throughput baselines, and no service-level objectives. While this flexibility lowers the barrier to implementation, it creates an ecosystem where:

  • Two catalogs can both be “compliant” yet differ by orders of magnitude in response time.
  • Clients cannot reason about metadata latency during query planning.
  • Synchronization behavior across catalogs becomes unpredictable.

In distributed data systems, predictability matters more than raw performance. Without a strict operational SLA—or at least defined behavioral constraints—clients are forced into defensive, retry-heavy designs that amplify load and increase tail latency.

The “List Tables” Problem: Cross-Catalog Sync Failure

The ListTables endpoint (GET /v1/namespaces/{namespace}/tables) is semantically straightforward. It allows clients to enumerate tables within a namespace and supports pagination through pageSize and pageToken.

The primary issue is not pagination itself. The real failure emerges when the same Iceberg tables are registered in multiple catalogs, a pattern that is increasingly common in hybrid and multi-platform deployments.

A Realistic Scenario

  • An Iceberg table is registered in Catalog A and Catalog B
  • Both catalogs point to the same underlying metadata and object storage.
  • One catalog is used by ingestion and streaming workloads.
  • Analytics engines or BI tools use the other.

The Sync Pathology

When a client connects to Catalog B and issues a metadata discovery operation—such as listing tables or syncing namespace state—the catalog must:

  1. Enumerate all tables
  2. Resolve metadata pointers
  3. Validate access permissions
  4. Reconcile the state with the underlying storage.

Because the REST specification defines no operational expectations:

  • There is no SLA for how long this sync should take
  • There is no distinction between a “lightweight” listing and a fully validated listing.
  • There is no mechanism to express intent (e.g., names only, no ACL validation)

As table counts grow into the tens of thousands, synchronization latency grows non-linearly. In practice, sync operations can take minutes—or fail—causing engines to stall, time out, or repeatedly retry.

The result is not merely slow metadata access. It is system-wide unpredictability. Query engines cannot determine whether a delay is transient, systemic, or catastrophic.

Latency Is Treated as an Implementation Detail—But It Is a Contract

The REST Catalog specification implicitly treats latency as an implementation concern. From a standards perspective, this is understandable. But in data-intensive systems, latency is part of the correctness contract.

The specification does not define:

  • Upper bounds on metadata retrieval latency
  • Maximum metadata payload sizes
  • Limits on metadata fan-out operations
  • The number of round-trip required to plan a query

As a result, a compliant catalog may require megabytes of JSON metadata and dozens of HTTP calls just to validate a single query plan. Engines appear slow and unstable, even though the root cause lies in an underspecified protocol.

This is precisely the class of problem Kleppmann warns about: correctness without latency guarantees is operationally meaningless.

Commit Semantics Under Contention: Undefined and Unfair

Iceberg relies on optimistic concurrency control. When multiple writers attempt to commit simultaneously, conflicts are expected and resolved through retries.

The REST specification defines the 409 Conflict response, but stops there. It does not define:

  • Backoff expectations
  • Retry fairness
  • Starvation prevention

In a multi-engine environment, this creates asymmetric outcomes. A high-frequency streaming writer with aggressive retries can permanently starve batch compaction jobs that follow conservative retry policies. Over time, table health degrades due to file explosion and unbounded metadata growth.

Once again, the issue is not semantic correctness. It is the absence of operational guarantees.

Caching Without a Freshness Model

While HTTP caching is permitted, it is not part of the correctness model. Support for conditional requests, ETags, or freshness validation is optional.

This forces clients into a pessimistic stance: always re-fetch, always revalidate, always assume staleness. The REST protocol degenerates into a chatty, high-latency control plane that negates its own architectural benefits.

Without a standardized freshness contract, caching becomes a gamble rather than a reliability tool.

Behavioral Conformance Is Missing

The Iceberg ecosystem has strong conformance testing for table formats. It lacks an equivalent for catalog behavior.

Today, “REST Catalog compliant” means:

  • The endpoints exist
  • The JSON schema is correct.
  • The happy path works.

It does not mean:

  • Predictable latency under load
  • Stable pagination during concurrent updates
  • Graceful overload signaling
  • Bounded retry amplification

Without behavioral conformance tests, compliance guarantees syntax, not operability.

Underspecification Is Still a Design Decision

The absence of operational constraints is not accidental. It reflects a deliberate choice to prioritize adoption and flexibility.

However, in distributed systems, underspecification pushes complexity downstream. It burdens clients, operators, and platform teams with the need to implement compensating logic. As Iceberg becomes core infrastructure rather than experimental tooling, this trade-off increasingly limits its reliability.

Semantic agreement without behavioral agreement leads to fragile systems.

Toward Operational Interoperability

Operational interoperability does not require rigid SLAs or centralized control. It requires acknowledging that latency, retries, and fairness are part of the interface.

Concrete improvements could include:

  • Defined operational profiles with minimum latency and concurrency expectations
  • Lightweight metadata views to avoid synchronization amplification
  • Standardized retry and backoff semantics for conflict scenarios
  • Explicit freshness and caching contracts

Semantic interoperability enabled Iceberg’s success. Operational interoperability will determine whether it remains dependable at scale.

Until then, the Iceberg REST Catalog remains a textbook example of why semantic specifications alone are not enough.

Plugins revisited

Mike's Notes

A reformat of the plugins listed in the industry workspace article.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

30/11/2025

Plugins revisited

By: Mike Peters
On a Sandy Beach: 07/11/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

This is an initial list of possible plugins, with a method and reference URL. Will be imported into the Plugin database and appear in the DevOps plugin editor workspace. Many of these will also be used in the demo workspaces.

This list will grow. Suggestions for anything useful are very welcome.

Method

  • iframe
  • blockquote
  • JavaScript
  • API
  • etc

Plugin Method Reference
AddThis    
Amazon Book iframe  
Apple Map    
Apple Music    
ArcGIS Map    
Atlassian Analytics    
Azure Map    
Cacophony API https://github.com/TheCacophonyProject/cacophony-web
CloudConvert API https://cloudconvert.com/api/v2/quickstart
CodePen   https://blog.codepen.io/docs/embeds/
CodeSandbox    
Confluence   https://community.atlassian.com/forums/Confluence-questions/Can-we-embed-a-confluence-page-content-in-a-website-without/qaq-p/2367532
Elfsight Weather    
Flightradar24 iframe https://forum.flightradar24.com/forum/radar-forums/flightradar24-web-page-and-apps/4383-select-an-aircraft-from-the-iframe-embedded-map
FormBlock    
GitHub-Embed    
GitLab Snippet    
Google Analytics    
Google Calendar iframe  
Google Docs iframe  
Google Form iframe  
Google Map iframe  
Google Meet    
Google Sheets  iframe  
Google Slides  iframe  
Instagram blockquote  
IUCN Threat Status    
Jira Advanced Roadmap    
JSBin    
Jupyter Notebook  iframe  
MailChimp    
Metservice Weather  iframe  
Microsft Forms    
Monaco Editor JavaScript https://stackoverflow.com/questions/73698181/embed-a-vscode-style-ide-in-the-browser
NASA Spot the Station    
NASA Worldview    
NetSuite Case Form    
NIWA CO2 Widget  iframe  
NIWA Tide Widget  iframe  
NIWA UV Widget  iframe  
NIWA Weather Widget  iframe  
Odoo Form    
PDF  iframe  
PostHog Analytics    
Survey Monkey    
Trello Board    
Trello Card    
TypeForm    
VesselFinder  API
JavaScript
https://www.vesselfinder.com/vessel-positions-api
https://www.vesselfinder.com/embed
Vimeo Video    
Weather Widget  iframe  
Wolfram Notebook    
Yandex Map    
Yandex Video    
YouTube Video  iframe  
Zoho Calendar    
Zoho Form    
Zoom Meeting    

I broke the CMS

Mike's Notes

The best way to learn is to make mistakes. Oops.

Resources

References


Repository

  • Home > PipiWiki > Engines

Last Updated

24/03/2025

I broke the CMS

By: Mike Peters
On a Sandy Beach: 21/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The integration experiment running live data through the Plug-in Engine (plu) and Learning Object Engine (lob) with the Content Management Engine (cms) didn't work.

It led me to discover a previously hidden issue with the CMS data model, which yesterday led to the model's change and the CMS's now-broken state.

To get the CMS working again, a lot of code must be revised. The Template Engine (tem) and the Render Engine (rnd) will also need minor altering.

However, with these complex changes, the integration to enable plug-ins and learning objects should now work in future.

I have been using a temporary workaround to successfully work with all 3 engines.

Plug-ins are necessary for two current projects;

  • my first customer needs live-sign language interpreters via Relay (a video service) embedded on their static website
  • Embedding Wolfram Notebooks on Pipi documentation pages
Learning objects are necessary for these tasks on the roadmap;
  • User documentation
  • the UI help system
I also realised that adding plug-ins and learning objects is not on the published roadmap. A job that is now done. (Roadmap wbs 4.1 - 4.5)

Learning Object

Mike's Notes

I'm figuring out how to integrate Learning Objects and SaaS Plugins into the existing, in-production Content Management System.

Update

Compare with Adobe RoboHelp, which is a CMS that can generate help documentation. There are similarities and differences.

Resources

References

  • IEEE Standard for Learning Technology—Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata IEEE Std 1484.12.3™‐2020 (Revision of IEEE Std 1484.12.3‐2005)

Repository

  • Home > Ajabbi Research > Library > Software > Architecture > Learning Object
  • Home > Ajabbi Research > Source > SCORM

Last Updated

14/02/2026

Learning Object

By: Mike Peters
On a Sandy Beach: 12/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I couldn't solve this problem until now because I needed both the Plug-in Engine (plu) and the Learning Object Engine (lob) to be under active development so I could see how they might integrate with the Content Management System Engine (cms). It is not proving to be simple.

Content Management System (CMS)

Since 2004, the CMS has undergone multiple versions and is now fast, robust, and mature. This integration will alter the data model and require a new version.

The CMS will provide all the content.

Metadata

Both the Plug-in and Learning Object engines describe CMS content with additional metadata about:
  • structure
  • relationships
  • names
  • properties
  • permissions
  • etc

Learning Object

Pipi needs learning objects nested in the Diataxis framework to provide structured user training and documentation. I am using a reduced-feature version of the original IEEE-standardised version.

According to Wikipedia, "The Institute of Electrical and Electronics Engineers (IEEE) defines a learning object as 'any entity, digital or non-digital, that may be used for learning, education or training.

Eventually, the Learning Object Engine (lob) will be available to assist enterprise SaaS applications with user documentation.

Embedding Wolfram Notebooks

Mike's Notes

My working notes on building the first plug-in.

Resources

References


Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/05/2025

Embedding Wolfram Notebooks

By: Mike Peters
On a Sandy Beach: 04/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I want to visually explain to Ajabbi users the maths that Pipi uses. I am not a mathematician, but I have learned to use maths visually in experiments and for analysing data.

Pipi

Pipi makes use of these kinds of maths:

  • Fuzzy Logic
  • Markov
  • Monte Carlo
  • Statistics
  • Algorithms
  • Etc

Ajabbi SaaS

The applications being built also need to use math directly, and users may need access to mathematical tools. The Pipi Content Management System Engine (CMS) generates the UI and content on every web page, so this means using forms rather than direct coding.

Wolfram

Last year, I took some free online training provided by Wolfram on creating and editing Notebooks. Afterwards, one of their people contacted me, leading to an open discussion about how to embed Wolfram Notebooks and maths training on the Ajabbi website.

One of their partnership people contacted me. They said that WordPress had also provided embedding. So, the first port of call is to see how WordPress does it.

Since then, Wolfram has kindly given me access to Wolfram One for three months so that I can experiment, test, and post some examples.

To do

  • Make the first plug-in to embed Wolfram Notebooks onto the ajabbi.com web pages using a simple web form.
  • Extend the plug-in to be generic and work with other 3rd-party websites.
  • Configure an embedded notebook to analyse live data at Ajabbi (I don't know how yet).
  • Embed free relevant maths instruction beside the notebooks.

WordPress

WordPress offers a plug-in for embedding content from third-party websites. The plug-in appears as a simple web form.

Embedding

Embedding makes use of the HTML tag iFrame.

Code

<iframe src="demo_iframe.htm" height="200" width="300" title="Iframe Example"></iframe>

Properties

Attribute Value Description
allow   Specifies a feature policy for the <iframe>
allowfullscreen TRUE Set to true if the <iframe> can activate fullscreen mode by calling the requestFullscreen() method
FALSE
allowpaymentrequest TRUE Set to true if a cross-origin <iframe> should be allowed to invoke the Payment Request API
FALSE
height pixels Specifies the height of an <iframe>. Default height is 150 pixels
loading eager Specifies whether a browser should load an iframe immediately or to defer loading of iframes until some conditions are met
lazy
name text Specifies the name of an <iframe>
referrerpolicy no-referrer Specifies which referrer information to send when fetching the iframe
no-referrer-when-downgrade
origin
origin-when-cross-origin
same-origin
strict-origin-when-cross-origin
unsafe-url
sandbox allow-forms Enables an extra set of restrictions for the content in an <iframe>
allow-pointer-lock
allow-popups
allow-same-origin
allow-scripts
allow-top-navigation
src URL Specifies the address of the document to embed in the <iframe>
srcdoc HTML_code Specifies the HTML content of the page to show in the <iframe>
width pixels Specifies the width of an <iframe>. Default width is 300 pixels

Creating an environment for plug-ins

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

By: Mike Peters
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.

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.