Showing posts with label no-code. Show all posts
Showing posts with label no-code. Show all posts

Pipi self-hosts and the chicken-or-egg problem

Mike's Notes

I wanted to write about why and how Pipi 9 is self-hosting and why this created a chicken-or-egg problem.

Pipi 9 is still largely headless, and I need to use the UI to build a UI.

Resources

References

  • Reference

Repository

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

Last Updated

17/05/2025

Pipi self-hosts and the chicken or egg problem

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

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

According to Wikipedia;

"An operating system is self-hosted when the toolchain to build the operating system runs on that same operating system. For example, Windows can be built on a computer running Windows.

Before a system can become self-hosted, another system is needed to develop it until it reaches a stage where self-hosting is possible. When developing for a new computer or operating system, a system to run the development software is needed, but development software used to write and build the operating system is also necessary. This is called a bootstrapping problem or, more generically, a chicken or the egg dilemma.

A solution to this problem is the cross compiler (or cross assembler when working with assembly language). A cross compiler allows source code on one platform to be compiled for a different machine or operating system, making it possible to create an operating system for a machine for which a self-hosting compiler does not yet exist. Once written, software can be deployed to the target system using means such as an EPROM, floppy diskette, flash memory (such as a USB thumb drive), or JTAG device. This is similar to the method used to write software for gaming consoles or for handheld devices like cellular phones or tablets, which do not host their own development tools.

Once the system is mature enough to compile its own code, the cross-development dependency ends. At this point, an operating system is said to be self-hosted." - Wikipedia

Part of the secret sauce of Pipi 9's success is its self-generating nature.

It's like watching the workings of a living biological cell, where hundreds of processes maintain and interact with each other. 

I had to manually create each engine and let them run against each other. It was a very slow and experimental process, like inventing a new cake recipe through trial and error. I stumbled across something that worked by accident.

As a result, it is headless. It has also been designed to generate its own no-code front-end, an HTML user interface for humans.

The current problem is that a no-code interface is needed to create the no-code interface. The lower layers of Pipi are supposed to help generate the UI and learn from user interactions, so a lot needs to be done, making it challenging to simulate.

This means the front end will go through many generations as Pipi learns from feedback loops to improve the UI further. The backend will also self-evolve.

So, it is slow, but progress is steady. And the more I get done, the easier and faster it will get.

So, back to that darn chicken, or is it the egg?

How to set Pipi configuration

Mike's Notes

Here are my notes from today's work on the Website Engine (wbs).

Resources

References

  • Reference

Repository

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

Last Updated

17/05/2025

How to set Pipi configuration

By: Mike Peters
02/02/2025

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

I'm manually migrating my first customer's website to Pipi's hosting. This is an excellent product test of the Website Engine (wbs), which sets up website hosting.

The next problem is enabling simple bullet-proof configurations for future customers to set up websites using no-code.

Each of the hundreds of modules will have many configuration options in the future, so a standardised system-wide process is needed.

This morning, I sketched some ideas on how the Admin User Interface (UI) might look.

This afternoon, I figured out that the Namespace Engine (nsp) already has a way to register the interfaces of every engine that is automatically built by the Factory Engine (fac).

I added another Interface Class Type, "Config", and solved the problem.

This allowed the fast addition of these examples of global properties that a website might have as options for the admin.

  • Meta Title
  • Meta Keywords
  • Meta Description
  • Domain Name
  • Default Language, e.g. eng
  • Plugins
  • Default Theme
  • Use References
  • Use See Also
  • Use Keywords
  • etc

Doing this also automatically generates config variable names used in internal messaging.

This would also enable configuration storage in XML or other open formats for interchange purposes and documentation.

This configuration system will also work for all the other engines and could be used for open-source SaaS applications.