Define what core means about makeen-hapi

[danmo]

I think it's all code that covers the core functionality:

• original backend and frontend boilers
• all modules that come in by default (users, email etc.)

So the core can also have modules/plugins etc., but they're required for the core to work so they can be core plugins ?

[Ameerplus]

@viczam @danmo @neekz0r ^^

[neekz0r]

IMHO, "core" is very simple and only has the base minimum for function. I would like for everything else to be plugins.

To me, the question is.. do we include plugins in the repo or have a separate repo? Both have their pros and cons. Thoughts?

[viczam]

Exactly.
Right now core is a plugin just like the rest of the functionality - https://github.com/viczam/makeen/tree/master/packages/core
It's written in a modular way so that it can be extracted into its own repository and node module (eventually). Actually, it's just that - a node module setup to work with the rest of things through lerna.

[viczam]

Right now it depends on makeen-storage, but I'm going to remove that dependency.

[neekz0r]

One other thing I feel strongly the core should be responsible for:

Checking versions of itself and plugins and notification to admins that there is a new version and/or security update.

[nicolasembleton]

Sorry my comment got stuck in my inbox. Pasting what I was writing 2 days ago:

Yes I think I agree with that. More importantly @neekz0r @viczam I also think that every plug-in will have its own life-cycle and probably it's own set of people that work on it (read maybe open source?) as well as its own license (for example open source or proprietary or else).

So I do think that core should be like the engine that glues the functionality, an executable, and the plug-ins should add on that as in, registering a new transport, a new cloud faas, a new docker-based-faas-ran-on-a-cloud-tool, a serverless logging plug-in, a filesystem simulator plug-in, etc...