Meeting between Russell Moore, Steve, and Brandon.

- From Steve - "Russell, we have missed you".

- Russell - Drawn back to the dream

- Like a beehive, everybody gets to play and the combined effort makes a difference

- All core adilas projects are going through our new gateway. Cory Warden is the gatekeeper for those projects.

- We have some snow owl CSS questions for Russell. We need the master back in the mix.

- Timeline views and other modern look and feel (flavor of the sites). These are things that we want to get back to.

- We want to focus on the Snow Owl Theme and get it all stabilized.

- Russell and Steve have had multiple conversations on the widget, app, pallet type interface - mix and blend different widgets and mini apps to help the users get their "space" setup. This is somewhat of a custom mini dashboard concept with lots of options and configurability.

Russell - wanted to pitch some ideas and things towards the adilas fracture project (future adilas project and plan). Making it a true core with an expandable platform type interface.

We started out in Postman (PHP based - API socket tool) and using Russell's auto generated API documentation - Tools with custom extensions for functionality, API sockets, classes, and view models. Core pieces all get add, edit, and view options for the data. Frameworks and then building on top of those. Russell was talking about core, custom core, themes, custom code, etc. These are ways that he could build on and virtually extend the core tool without hurting the main core logic.

Some of the concepts were dealing with the pallet type view (multi mini windows or widgets). They were talking about how to use tons of mini widgets, apps, views, and even third party tools - all mixed together in one app. We started talking beyond screen, and screen size, and going more to a canvas type view. A canvas is a layout design that may be bigger than a screen. They would like to be able to navigate to different sections, zoom in/out, call something into focus, and the background pieces would connect with both internal and external API sockets. Once the data structure is known, the building out of things becomes very quick. The goal is to create a robust back end engine that could be built out and modified on the frontend very quickly. Getting back to cores (internal core) and plug-ins or add-on's.

Both frontend and backend developer widgets and backend components - Russell was proposing a table component (just like the data tables, but more robust and configurable). Components are able to worry about their size vs screen size. Basically, you could make the components smart (know its own parameters). As you start mixing different components, make each one smart enough to mix and interface with other widgets without being overwritten and/or altered. Tons of self-contained mini apps all working together.

I was asking Russell about some of things that he is working on. One of them was what he was calling "Headless CMS (content management systems)" - All API socket connections but no real structure. Virtually a brain without a face. The face becomes the view model. We talked about how adilas uses a similar concept called "play at the wall" type concepts - All API socket connections without having a required view of that data. Russell was getting back to classes and specific tools and object oriented programming. If we use a tool too much (say elements of time), it can make the water muddy. That is both good and bad. In some ways, it makes it very flexible. In other ways, it may actually get abused because it may be used in so many different ways.

Lots of separation between database, views, logic, uses, tools, and data. Some of the new pieces (on the view model) could be scrolled, slid, collapsed, expanded, shrinks, etc. Kinda like the old Adobe Flash Rich Interface Environments but without the Flash wrapper. Beautiful interfaces with just in time data, fun navigation, built-in validation, etc.

At some point, we would love to allow our uses to use what pieces and features that they want and then working on charging based on what they are really using. Maybe thinking of being out on the AWS stuff for this. Still just ideas and concepts.

We also talked about running with two ships vs just one (different applications) - see screenshots (build on both apps and eventually have two separate products). Ideally, the new ship (say adilas fracture) would end up being a more powerful tool and a full remake of the original adilas model. Little by little, chipping away at the new system and new structure.