Gothic

The successor to Ghost and Lapiz.

Gothic runs in Go on a dedicated server. It is not meant to run behind Apache or share the machine with other services. But it can make efficient use of very small machines and scale out to utilize additional nodes efficiently.

Components

• Blueprints: schemas, data designs
• Mason: server level compiler
• Carpenters: UI (JS,CSS,HTML) compiler
• Arch: UI runtime
• Vault: Persistance
• Portal: API/transport
• Spire: UI
• Lancet: Core(server) framework

Blueprints

Gothic is built around blueprints. A blueprint is like a model or schema. It defines a set of data and it's relationships.

Blueprints also define special modifies for:

• UI
• Storage
  • non-persistant fields
  • manually defined indexes
  • auto-indexing
• API
• Validation

All instances are entities. They have an id field, a guid.

Arch

This is the hard bit. How to take the blueprints and translate them to something powerful, mostly automated, but still flexible.

I think it will use 2 Web Workers + the main window by default. One worker will handle any processing, the other will handle networking. If the models are all encoded as ArrayBuffers, they can be passed around easily. I can also translate their code to Asm.js. But this means they cannot interact in Asm.js.

Unlike Lapiz, I will not do strict privacy, instead relying on the compiler to enforce this.

Just figured out function tables in Asm.Js, that puts a lot back on the table.

Vault

I'm torn on this. I may use a no-sql (I think mongo). But I may be able to handle this in Go very efficiently.

Caching has 3 layers. Active, cached and stored. Active objects are currently reachable and cannot be garbage collected. This will require weak refs so that I can hold a pointer to the object without preventing finalization. The next level is cached. When an object is finalized, it gets moved to the cache, this can be a strong ref. When an object is requested from cache, it's also removed from cache, because it's now active. Lastly, there is stored. After the GC runs, we look at the memory profile. If more than 80% of memory is consumed, we clear some percent of the cache. When an object is removed from cache, it is serialized and stored in a file.

To store data, it needs an ID and a way to be serialized. I'm going to use byte arrays for IDs, they're incredibly flexible.

Note: may want to look at protocol buffers

Crazy Idea

Go has function pointers and unsafe. It may be possible to generate Go code, spin it up in separate process, pass a pointer through a pipe, and copy the function.

Spire

This manages CSS and HTML templates. I want something very much in line with LapizUI. We have Templates and Meta-Templates. They are logic free and instead expose hooks that need to be handled in application logic. When an entity is merged with a template it can be rendered to a target. A Meta-Template can be merged with a blueprint to produce a template.

Themeing is broken up a bit more here than in most frameworks. One portion of themeing handles page blocks.

Templates and Meta-templates have types (edit, create, full, short, list) and are arranged in packages (though a single template can be a package). It will be possible to request that a specific template or meta-template be used in some instance, but the more common procedure will be to choose the type and have the theme engine choose the best fit. This will be done with a precedent order. So a theme will ship with some default meta-templates. Modules can define their own templates (for their types).

Credential Model

There are two types of credentials. One is token access. This is where a user or process gains access by having access to a token object. The other is secret knowledge. This is like a password.

Using a CMS as an example; a user could sign in with a username and password. Now they have this credential object to access and edit content. But rather than giving each user access to individual objects, we create roles, which are access tokens and user object is only used to retrieve a role token.

Portal

This is the API layer. It primarily works over websockets. A user or process provides a request. The system uses their credentials to see if they have access to the results of the request. The objects that match, that the requester can access, are returned.

Though Experiments

• Basic relay chat server
• Wiki
• Work logs