Core v2: Port core to the Slim framework

[Joost De Cock]

The goal is to port core the the Slim framework, the same that we use for our data backend.

As this will be a bit of work, you may wonder why bother? Here are some of the reasons:

Make it easier for developers to get involved

Core is currently entirely home-grown. This means that for people to get it they have to dig through a lot of code to figure out how things fit together.

Using a framework like slim means that people (who know the framework) don't need to figure out how we do things like dependency injection or routing. Instead they (and us) can focus on that part of the code that is more relevant.

This should lower the bar for other developers to contribute to core which is an important factor in the longevity of any open source project.

Get rid of channels

The idea to have different channels so that other people can run core in a different way is probably a bit over-engineered. Rather than having channels to maintain, this should be handled by making core more configurable, and more easy to adapt to different input formats.

Make core more modular

Core has some support for this, but the implementation is not optimal. For example, you can use your own themes or patterns, but doing so is non-trivial without maintaining your own fork.

The idea is reduce core to its... core, and let composer handle dependencies.

In practice, this would mean that:

• Themes would be maintained in their own repository. Adding a different theme should be as easy as running composer require your-theme-here
• Patterns would be maintained in their own repository. This would allow us to add patterns to core through composer, but also clarify things. As in, it would prevent us from having to bump the core version number any time we make a small fix in a pattern. In addition, it will split the changelog into more relevant changelogs per pattern.

The idea is to set up some composer meta package that would bundle all stable patterns, and perhaps a beta meta package for all beta patterns.

Make sampling/measurement loading easier

Today, it's up to the pattern designer to provide default measurements for the drafting of the pattern, as well as for sampling/comparing.

This is not a burden we should place on the designers. Instead, we could just provide a set of measurements that can be applied to all patterns.

We could also allow core to pull in measurements from the data backend, although this should probably be optimal.

If you have other ideas, or would like to help coding/designing the core-v2, don't hesitate to weigh in below.

[Joost De Cock]

Change of plans :)