Some points of the architecture may still be discussion: check the issue tracker for more up to date information.
The project will be composed of the following components, one per repository and communicating through REST APIs and Git where applicable:
-
a CI system like Drone or Travis, that compiles and deploys the book. Can be configured through a
.ymlconfiguration file in the repository.- The book compilation system runs inside the CI. We might have to modify existing systems to adapt them to our project, such as MultiMarkdown 4 or Marked.
-
an editor frontend that takes a repository and makes commits such as Prose. The editor must also consider configuration options in the
.ymlconfiguration file, so that the preview it offers matches the CI's compilation. -
the output files hosting. Several alternatives exist for this, depending on the output generated by the CI. For example, Softcover can serve as a sales front-end if the book is compiled with their software. GitHub pages can serve as a static website frontend if a Jekyll site is generated (containing the PDF, etc.)
-
a thinly modified GitLab that contains the issue tracker, file browser, user profiles and cohesively glues all elements together.
While all components already exist in some form, the great challenge is putting them all together into a coherent whole.
This project will decide on a suitable default for the compiler,
and make each component work sensibly with that default.
Next we shall consider widening the possibilities,
while maintaining coherence through the .yml configuration file.
Advantages of the modularization:
-
individual components may be used for multiple existing systems, increasing potential user base. For example, the CI compiler and the editor could be used as well on our modified GitLab interface as with GitHub or Bitbucket.
-
easier to rebase on top of the individual projects
-
easier to merge back to those projects