Cloud native Mumps

[rafi farchi]

Subject: Exploring a Cloud-Native, Multi-Model Approach to MUMPS: A Kotlin Runtime with PostgreSQL Backing (Seeking Technical Feedback)

Hi everyone,

As someone who deeply respects the power, speed, and elegant multi-dimensional array design of MUMPS—which continues to run some of the most critical systems globally—I have been exploring new architectural paradigms to bridge legacy strengths with modern cloud infrastructure.

We all know the historic challenges of mapping MUMPS globals onto relational databases (network latency, impedance mismatch, and gridlocks on loops). However, instead of trying to force MUMPS to be "just relational," I’ve been developing an experimental, lightweight runtime engine in Kotlin that decouples the execution layer from the physical storage layer.

I wanted to share a technical whitepaper summarizing our progress and physical Proof-of-Concepts, and I would be incredibly grateful to get your honest, constructive feedback.

Link to the Document: https://www.test-prep.oo.gd/KotlinMumps.html

A few core concepts we are testing in this advanced implementation phase:
1. Centralized Code / Custom Bytecode: Storing the original MUMPS source in a central repository table, compiling it dynamically into a proprietary, highly optimized Custom MUMPS Bytecode that executes on local edge clients (compiled as light .jar nodes).
2. Asynchronous Decoupled Cache (GL2MEM): To solve the remote cloud latency issue, we implemented a custom dual-map in-memory cache blueprint. During intense loops, a single bulk-fetch pulls a global subtree, allowing downstream GET and ORDER routers to run in O(1) constant time locally. In initial stress tests on standard mobile hardware (Termux/Android) talking to a free cloud Postgres instance, this hybrid router achieved a ~754x performance increase over uncached remote queries.
3. Multi-Model $Sql$ Extension: A planned feature allowing developers to safely execute standard DML/DDL queries targeting native, production-grade PostgreSQL tables right inside standard MUMPS subroutines—mixing the best of both worlds.
4. Consistency & Concurrency: Utilizing PostgreSQL's MVCC capabilities to map explicit COMMIT/ROLLBACK commands, alongside a logical lock table to preserve standard MUMPS resource-blocking semantics without locking physical DB records.

This project is not an attempt to replace traditional, high-performance engines like YottaDB, but rather an exploration of how we can deploy a lean, cloud-native MUMPS interpreter tailored for specific hybrid environments and modern web-server integrations (using bidirectional JSON-to-JS communication).

Given the immense expertise in this group regarding VistA internals, database design, and the intricacies of $ORDER sorting, your insights on our caching strategy, transaction boundaries, or potential structural blind spots would be invaluable to me.

Thank you so much for your time and for keeping this incredible technology moving forward.

Warm regards,
Farchi Raphael