Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Make SpecElektra easier and safer to use #1683
Some Ideas how the upcoming type system can be integrated in Elektra in various
I think there are basically two target groups, called users and writers. I tried to categorize my integration ideas to target either one or both of these groups.
Writers are people who develop specifications for the use with Elektra.
Users use specifications to validate their configuration when mounting new
This can also make use of type inference, as it would allow the writer of a
It should be kept in mind that the typesystem should be optional and thus can be
(Users) libtools integration / specmount
One way is to integrate the type system in libtools, specifically in the smount
To integrate this for all kinds of tools, we can add these kinds of checks to
(Writers) kdb editor integration
An easy way to integrate the type system in a specification writer's procedure
Furthermore we can add a parameter to automatically add inferred types to the
A downside is that there is not really a direct feedback possible as usually
(Writers) libtools integration / merging
kdb editor, suggested above, uses the merging framework of libtools. So instead of
A little downside is that kdb editor also offers custom conflict strategies which don't
(Both) global plugin
Another way is to write a global plugin that watches for changes in the spec
This would work for both authors and readers in a general way, though its not
(Both) Standalone tools
We can offer standalone tools (or expand the kdb tools with something like
These are quite nifty ideas!
I like your idea of having the specification validation as plugin best. Remarks on this idea:
Your idea can also applied on a more general level. For example, we could write plugins (maybe they even use your type system), to protect system/elektra/mountpoints from invalid mountpoints or even individual plugins from wrong plugin configuration.
@petermax2 actually had a quite similar approach with
We should not keep such behavior undecided. An important goal of your type system is to unify current ad-hoc solutions #1092. Users rely on getting deterministic results.
I like this option but I think we should opt against it. While it might be very interesting to use such advanced knowledge to find better merging solutions (@fberlakovich might even have anticipated such ideas and kept the merging strategies very modular for this very reason?) we are at a terrain with little knowledge what works well. It would be a topic quite different to your ideas discussed so far.
To move forward it might be best to start writing decisions of how the errors and plugin interface needs to be.