Hi David, I would challenge SFM460 - The feature model should provide an externally accessible API for reading and writing feature files
The model itself doesn't provide any API nor would it mandate any implementation detail. I rather see this partially as refinement of SFL012 - Tooling must provide a way to add new features to an existing application. and it also might be some tooling for remote editing and distribution of features & application state. My thought for this was to implement something like a deployment manager which is a tool to compose and build up new features and queue up for the next deployment. So instead of dynamically installing bundles & content one would have a tool (which should be built with API-first in mind) to a) build up a new feature based on available artifacts (bundles, packages, configs, repoinit commands) b) compose an application based on installed application state (features as deployed in last deployment) and new features c) queue up an application state for deployment & trigger deployment (defining the interface to the operational details such as the launcher or in containerized environments the coordinating system) The bullet points ahead account for local deployments (in instance preparation & triggering) - as well as for remote execution where some coordinating system would be use to centrally coordinate application state of n instances and distribute the results accordingly. We should properly split up the modeling (deployment manager) from the operations details (feature model distribution) so we can plug the distribution system according to the operational details (local, distributed topology, multi topology system) while reusing the same mechanism for adjusting a versionable model (which can distribution wise map to 1 or n systems). Cheers Dominik On Fri, Mar 16, 2018 at 10:48 AM, David Bosschaert < [email protected]> wrote: > Hi all, > > In the mean time some additional requirements surfaced, which I added in > [1]. > > I also updated the feature model format, mostly based on existing > requirements. It can be found at [2]. Once it's matured we should create a > JSON Schema for it (or something similar)... > > Main additions are: > * Support for variables > * Comments can now also be put in the document by using a key that starts > with a hash '#'. This is because most JSON editors don't support the JSMin > (/* */ and //) style comments and show these as errors. > * Some small additions that make it possible to 100% roundtrip between the > provisioning and the feature model which is especially important during the > phase where users are migrating. > > Best regards, > > David > > [1] > https://github.com/apache/sling-whiteboard/commit/ > 2dcab0e45866ce51f732ac525ebf100a82737099 > [2] > https://github.com/apache/sling-whiteboard/blob/master/ > featuremodel/design/feature-model.json >
