Sunset required functional and non-functional requirements on extensions
Closed this issue · 5 comments
From looking around on forums and blogs there seems to be a single thing that everyone sees as a challenge to the Joomla project: velocity of development
I think the following reasons have some part to play in this:
- lack of resource (though there will never be enough)
- NIH syndrome (not invented here syndrome), ie. Joomla framework
- No plan to replace library or architecture from the start
- No plan to adopt certain technologies in time frame
The best solution would be for Joomla to provide leadership in setting these requirements and plan the implementation of them. I'm not talking realistic development plans, but rather agreed business processes.
I.e.: If we are deciding to have orthogonal functionality, when are we going to enforce extensions having to have implemented this?
If we can't decide on this time frame, why would not just everyone roll their own?
IMO it's not Joomla's role to impose any requirements on how extensions are structured. This enables extensions to implement their own MVC layers as an example instead of using Joomla's core layer to create custom toolsets. The only timeframe requirements that should be imposed is if any core feature is deprecated, and it would indicate what release the code will be pulled out of. Telling extension developers they cannot use their own middleware layers and mandate an implementation of a core structure would be murder for the extension ecosystem.
Ok, but thats exactly the point I am making. Is it the core teams position that "build your own" is preferable?
You do remove unsecure extensions from the JCE, as well as Joomla 1.5 extensions and non-GPL extensions.
Not encouraging people to move forward is causing damage as well. I don't really want to quantify it, as it leads to a "good enough" argument
If your argument is that "build your own" is bad, then I want to be as bad as I can be. There should NEVER be a requirement that components implement the core MVC layer, or whatever over-engineered solution comes out of the J4 group. Have you not seen platforms such as redCORE or FOF or Nooku? Your suggestion effectively mandates that those layers must follow core rules and are therefore bound to the same limitations as the core system. Try telling redWEB or Akeeba or Joomlatools their extensions are no longer welcome on the JED because they aren't following the core conventions.
As far as JED policy goes with license enforcement or removing listings for unsupported CMS versions, take that up with the directory leadership; it's got nothing to do with code structures.
Joomla!4 will use external libraries a lot. Decision is made about the Doctrine DBAL (not the ORM), Same is true for Flysystem abstracting the filesystem. It does absolutely not make sense to maintain such stuff ourselves. So, we're healing the NIH syndrome a lot.
It is intended from the J4WG to flag extensions on the JED, if they don't follow the recommendations. So, when an extension does use SQL code directly, or accesses the filesystem directly, potential users will get warned, that they might run into troubles, if they use those extensions. However, at the current stage, this is intention and not decided finally.
No action required, closing.