Welcome to Yorkton Code Fractal
| Prev | Home | Next |
Welcome to the Yorkton Code Fractal and MSS (Mark Stephen Sobkow) Code Factory project pages. Yorkton Code Fractal is the successor to MSS Code Factory, a major refresh of the technology and approach used for the code base which really shares very little with the prior knowledge base and code structure that produced the 2.13 code architecture.
2026-10-18 00:00 CST MSS Code Factory alpha13 EBF 202610180000 released at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/2.13.42-alpha13-ebf-202610180000. You can find installation instructions at https://github.com/msobkow/org.msscf.msscf.v2_13-installer and the README.md displayed there. There have also been releases of the 2.13 knowledge base and model set as of 2026-10-18 00:00 CST, tagged as 2.13.42-alpha13-ebf-202610180000 which are included in the installer and are required alongside the executable jars to run the tool. Alpha13 shifts gears temporarily to working on TeaVM support to allow for cross-compilation to JavaScript for deployment of the web clients, which will connect directly to the back end using the same code base the back end is coded with. I haven't finished the CodeVis changes yet, though a huge amount of that work is now complete, and I haven't forgotten about the Role implementations.
Yorkton Code Fractal (formerly MSS Code Factory) is a tool used to accelerate the production of the repetitive code that comprises 75-95% of the typical enterprise business application - the "glue" between the business logic programmer and the backing data servers and databases. It does so by applying a knowledge base of General Expansion Rule (GEL) files following specific XML document schemas and semantic constraints to a Business Application Model (BAM), which is an enhanced ERD constrained by a customized schema definition available here: mssbam-2.13.xsd, with 3.1 using an updated ycf/3.0.1/xsd/mssbam-3.1.xsd specification adapted to the new capabilities of the customized CFCore Engine eventualy implemented for the 3.1 BAM.
The BAM defines the tables, indexes, and relationships of an ERD, including Superclass, Container/Component, Parent/Child, and Lookup relationships. It also provides the means of encapsulating customizations of the output source code, with the approach changing radically compared to the old 2.0.12/2.0.13 approach of hard-coded verbs in the custom engine. Both 2.0.13 and 3.1 implement "tweaks" (see prior section on enhancements and improvements.)
I invite you to read through the prototype architecture and philosophies, and through the 2.11 documentation. Although seriously stale about the details, most of the key concepts and descriptions about how the CFCore engine works as described in the 2.11 documentation are still valid to this day.
The diversion into working on TeaVM support is proving very fruitful and should yield the end results that I want, provided I invest sufficient time in ycf-core and ycf-msscf, especially in the YCFMt objects that underpin all the multithreading of the tool and applications produced by it. In the end, one should be able to connect a TeaVM-compiled JavaScript client to the back end services over both JSON and binary stream protocols, where the JSON form will be used with HTTPS GET/POST requests, and the binary stream protocol will be supported by Web Sockets. A long-in-the-tooth ASN.1 technology is being used to implement the lowest level of the binary stream protocols, and will ensure that the only thing to debug is the message formats, not the binary representation of the message contents.
JSON will rely on the existing Xml type formatting and parsing provided by IYCFXmlUtil/YCFXmlUtil. The goal of the current refresh is to ensure that there is full n-way orthogonal comparison and construction between the various atomic types in the core code base, including the new KeyHash types, and possibly the idea that keys and indexes of all times should generically be treated similar to the atomic types, and exhibit full orthogonal behaviour. The code base is well on its way to implementing full orthogonality, with comparison and assignment between index keys, buffer records, history buffers, primary keys, and history primary keys. If full orthogonality is available, then it becomes possible to more easily stitch together the resulting code with set constructs for easy filtering and processing.
Next up after I'm done working on the core Java and JavaScript code base with JPA support will be support for Rust, and later C-sharp and Python. There is good support for C++ through existing Rust binding technologies, so no particular special effort will be put into supporting C or C++ - Rust binding will be counted on for those and for all other language bindings.
Rust will be a relatively easy language to support, as it's primitives are clear and understandable and it is at heart an object-procedural language. The binary stream protocol provides a binary Rust implementation which will be used as a template for "how to code the Rust support I need", give or take some heavy focus on porting ycf-core at the start of the effort. Depending on how things fall out of the binary stream code, the buffer objects and index keys might change over to using the raw binary stream for data storage, and translate that stream to Java objects for manipulation. That would ensure that all objects are ready for instant transmission upon request with no further processing required to produce the desired data streams. Although this would impact the performance of individual server nodes, as they'd be responsible for the most code conversion to perform their task, but you either end up CPU bound on converting to data stream buffers every time you communicate, or you end up CPU bound on converting buffers for data _processing_ except for the core JPA service implementations that are based on raw Java types, but maximimize web throughput for the node. I've opted to optimize web throughput and rely on clustered nodes for scaling the servers. With this approach, the heaviest CPU load is on the user's web UI running in the browser with the Java/JavaScript TeaVM support code - it not only engages in translation every time a user event is processed, it has to translate each and every field and attribute access in the code base. The web server only does translation on the buffers it is sending or receiving from the JPA layers; the communications to clients are maximally efficient and re-usable, and the web service code runs in the JPA implementation layers that rely on native Java bindings.
So unlike the architecture behind MSS Code Factory 2.13, the code base behind Yorkton Code Fractal 3.1 is based on actual field experience at producing optimal communications and database access implementations. Everything else just falls out of that as near-optimal and flexible code that makes it easy to use with any web interface framework you choose to leverage that can be counted on to load a large page of JavaScript and then do all it's processing throuh DOM manipulation in the browser via JavaScript. The approach being taken to the JavaScript code means you can even mix and max frameworks for different portions of the final application code base, providing the developer with full freedom to implement their web clients using any web-client technology that leverages JavaScript.
I also have some ideas aroud data filter definition and processing in conjunction with event-based condition evaluation and propagation that could yield some interesting results for deploying the actual business logic behind a system in as reusable a fashion as possible. To be honest, I wonder if I'll ever be done with my code base, or if I'll still be working on it the day they strap me into an extra-long-sleeved jacket for permanent residence in a rubber room somewhere...
I'm not ambitious! :)