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.

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.

Why do it in Go? Store the data as Gobs. I can store data in a memory cache. I can watch memory usage and when it get too high, start removing cached items, or dropping indexes to disk. I can also watch for what indexes are most used, least used and what indexes would help with queries.

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).

Though Experiments

• Basic relay chat server
• Wiki
• Work logs