Gothic: Difference between revisions
Adamcolton (talk | contribs) Created page with "The successor to Ghost and Lapiz. == Components == * Blueprints: schemas, data designs * Mason: server level compiler * Carpenters: UI (JS,CSS,HTML) compiler * Arch: UI runti..." |
Adamcolton (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
The successor to Ghost and Lapiz. | 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 == | == Components == | ||
| Line 15: | Line 17: | ||
Blueprints also define special modifies for UI, Storage and API. | Blueprints also define special modifies for UI, Storage and API. | ||
== 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. | |||
Revision as of 19:38, 2 September 2015
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 and API.
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.