Maybe we should refactor core plugins to stay in a different directory, to better give the idea that they aren't mere plugins.
For the effects of this RFC, and until a better name is proposed, I'll name such core-plugins of modules (to reflect specialized functionality).
The heart of this issue is that I can't understand why the core plugins have been created... Why has this functionality been extracted from core to separate plugins? (@MMN-o)
Move everything to actual plugins (hard-work, requires making everything actually dynamic)
Re-integrated all the core plugins into core (hard-work, means reverting everything)
Refactor core plugins to "modules" and fix issues with the ActivityModeration plugin (reasonable, but it doesn't make sense to accept this change if there was no reason to extract core code to plugins) (other than avoiding the hard work)
Let's forget all this and do nothing
About ActivityModeration: This one is listed as core but all the core-code related to notice elimination was not ported to the plugin, contrary to what was done with the Favorite plugin.
Maybe we should refactor core plugins to stay in a different directory, to better give the idea that they aren't mere plugins.
For the effects of this RFC, and until a better name is proposed, I'll name such core-plugins of modules (to reflect specialized functionality).
The heart of this issue is that I can't understand why the core plugins have been created... Why has this functionality been extracted from core to separate plugins? (@MMN-o)
Another thing that confuses me is:
* The core plugin list has been created in 19 Oct 2013: https://git.gnu.io/gnu/gnu-social/commit/2a5ba1f74bb428fc74f181f806aa786b04b48d0a stating that they cannot been disabled.
* The Favorite plugin was created in 24 Jun 2014: https://git.gnu.io/gnu/gnu-social/commit/db7cc7fa7553e0be302d518360648940756f131c suggesting that it is optional.
I think that we now have four options:
1. Move everything to actual plugins (hard-work, requires making everything actually dynamic)
2. Re-integrated all the core plugins into core (hard-work, means reverting everything)
3. Refactor core plugins to "modules" and fix issues with the ActivityModeration plugin (reasonable, but it doesn't make sense to accept this change if there was no reason to extract core code to plugins) (other than avoiding the hard work)
4. Let's forget all this and do nothing
About ActivityModeration: This one is listed as core but all the core-code related to notice elimination was not ported to the plugin, contrary to what was done with the Favorite plugin.
Why has this functionality been extracted from core to separate plugins?
rozzin: If you look at changes when FavoritePlugin became a thing, for example... a lot of stuff got aggregated together more logically--the answer to "where is the code implementing favorites?" changed from "oh, all over the place..." to "in plugins/Favorite".
rozzin:
I think I'd strongly suggest "module" over "library" for an application-level
mechanism like this.
But it might make sense to just move the "core modules" into subdirectories of lib.
e.g. lib/Favorite.
I just don't want to have to figure out linguistic constructs like "these modules
in the modules directory are the non-modular modules and the plugins are
the modular modules" :)
"library" has a lower-level connotation;
XRevan86:
I think "module" is good.
modules are not necessarily non-essential.
Given that both directories (plugins and modules) would be in GNU social root, and "modules are not necessarily
non-essential", it's maybe better to go with modules, as core-plugins might not be "as lower-level" as the other lib/ resources.
For reference (raised by rozzin):
* http://foldoc.org/module
* http://foldoc.org/library
* http://foldoc.org/plugin
> Why has this functionality been extracted from core to separate plugins?
rozzin: If you look at changes when FavoritePlugin became a thing, for example... a lot of stuff got aggregated together more logically--the answer to "where is the code implementing favorites?" changed from "oh, all over the place..." to "in plugins/Favorite".
rozzin:
I think I'd strongly suggest "module" over "library" for an application-level
mechanism like this.
But it might make sense to just move the "core modules" into subdirectories of lib.
e.g. lib/Favorite.
I just don't want to have to figure out linguistic constructs like "these modules
in the modules directory are the non-modular modules and the plugins are
the modular modules" :)
"library" has a lower-level connotation;
XRevan86:
I think "module" is good.
modules are not necessarily non-essential.
Given that both directories (plugins and modules) would be in GNU social root, and "modules are not necessarily
non-essential", it's maybe better to go with modules, as core-plugins might not be "as lower-level" as the other lib/ resources.
includeals> > [rozzin] I'm kind of liking the "just put the core modules into lib along with all of the other `library' code".
<includeals> As said eariler, I don't dislike that path either. But at an implementation level, not everything in a module is library code, in fact, modules haver their own lib/ as well as action/, etc.
<includeals> `modules` are more generic, which is good also, with v2 structured divided in includes and public, modules makes it easier to respect that structure.
<includeals> > <lnxw37d4> So how about /plugins for 3rd party optional modules; /modules/optional for optional modules included with GS & maintained by the project; /modules/core for required modules? Abandoned or unmaintained modules could go in a separate repo, so admins would know that they may not work or may be insecure.
<includeals> We already have local/ for 3rd party optional modules, if we can keep backwards compatible without seriously bad consequences, we should
<includeals> > <dansup> IMO plugins should become their own packages/git repos, that way, they can be maintained without having to require core updates
<includeals> I confess I have mixed feelings about this... But lets leave that for another discussion.
<includeals> rozzin: Also, modules still make use of the plugins system, the real twist is that they cannot be turned off
<xmpp-gnu> [rozzin] more like "plugins make use of the module system"
<xmpp-gnu> [rozzin] the awkwardness in GNU social WRT `some weird things that are "plugins" are things that are strange to be "plugins"' seems to be that the codebase from StatusNet generally had a lot of spaghetti to it, and the only place where was initially any attempt at providing any sort of clean organization was for plugins
<xmpp-gnu> [rozzin] because you can't really even do actual plugins (i.e. drop-in/addon-on modules that might be developed/maintained outside of your project) if you don't have any sort of module system
<xmpp-gnu> [rozzin] but aside from plugins, I don't think StatusNet really cared about modularity / separation of concerns (or really `design' in general, I guess...)
<xmpp-gnu> [rozzin] so they called their modules "plugins" and they called the API the "plugin" API..., because that's the only kind of modules they had.
<xmpp-gnu> [rozzin] And I think mmn just didn't bother trying to fight/convert the terminology when he started refactoring everything to have better boundaries.
<xmpp-gnu> [rozzin] "whether they're called Plugins or Modules" was kind of the least of the concerns around that time--
<xmpp-gnu> [rozzin] there was a lot of stuff that just didn't even work right, IIRC.
<xmpp-gnu> [rozzin] and then we'd start trying to fix that stuff, and run into that `wait where is the code for that even located?' issue.
<xmpp-gnu> [rozzin] I can't really say what was going on in mmn's head at the time, but I'd say something like "OMG. It's spread out all over the place? Again? I'm just going to separate this stuff out now, because I can't maintain this otherwise" is probably a good guess.
includeals> > [rozzin] I'm kind of liking the "just put the core modules into lib along with all of the other `library' code".
<includeals> As said eariler, I don't dislike that path either. But at an implementation level, not everything in a module is library code, in fact, modules haver their own lib/ as well as action/, etc.
<includeals> `modules` are more generic, which is good also, with v2 structured divided in includes and public, modules makes it easier to respect that structure.
<includeals> > <lnxw37d4> So how about /plugins for 3rd party optional modules; /modules/optional for optional modules included with GS & maintained by the project; /modules/core for required modules? Abandoned or unmaintained modules could go in a separate repo, so admins would know that they may not work or may be insecure.
<includeals> We already have local/ for 3rd party optional modules, if we can keep backwards compatible without seriously bad consequences, we should
<includeals> > <dansup> IMO plugins should become their own packages/git repos, that way, they can be maintained without having to require core updates
<includeals> I confess I have mixed feelings about this... But lets leave that for another discussion.
<includeals> rozzin: Also, modules still make use of the plugins system, the real twist is that they cannot be turned off
<xmpp-gnu> [rozzin] more like "plugins make use of the module system"
<xmpp-gnu> [rozzin] the awkwardness in GNU social WRT `some weird things that are "plugins" are things that are strange to be "plugins"' seems to be that the codebase from StatusNet generally had a lot of spaghetti to it, and the only place where was initially any attempt at providing any sort of clean organization was for plugins
<xmpp-gnu> [rozzin] because you can't really even do actual plugins (i.e. drop-in/addon-on modules that might be developed/maintained outside of your project) if you don't have any sort of module system
<xmpp-gnu> [rozzin] but aside from plugins, I don't think StatusNet really cared about modularity / separation of concerns (or really `design' in general, I guess...)
<xmpp-gnu> [rozzin] so they called their modules "plugins" and they called the API the "plugin" API..., because that's the only kind of modules they had.
<xmpp-gnu> [rozzin] And I think mmn just didn't bother trying to fight/convert the terminology when he started refactoring everything to have better boundaries.
<xmpp-gnu> [rozzin] "whether they're called Plugins or Modules" was kind of the least of the concerns around that time--
<xmpp-gnu> [rozzin] there was a lot of stuff that just didn't even work right, IIRC.
<xmpp-gnu> [rozzin] and then we'd start trying to fix that stuff, and run into that `wait where is the code for that even located?' issue.
<xmpp-gnu> [rozzin] I can't really say what was going on in mmn's head at the time, but I'd say something like "OMG. It's spread out all over the place? Again? I'm just going to separate this stuff out now, because I can't maintain this otherwise" is probably a good guess.
As noted by XRevan86, modules are not necessarily non-essential.
As we will keep the modules directory in GS root [therefore, near to
plugins/], it is evidenced the difference between both.
This is a simple yet fundamental structural change. It doesn't change
functionality but makes clearer the way we understand GNU social's
internals.
2.
[CORE] Refactor Plugin API to Module API
Relevant commits:
1. https://notabug.org/diogo/gnu-social/commit/4cee29ab5c1317f1794ae45dc85591670ad15d06
2. https://notabug.org/diogo/gnu-social/commit/af31848400531406a18cacc66b1f4b8753254568
1.
> [CORE] Move core plugins to a new modules directory
>
> For reference (raised by rozzin in IRC):
>
> * http://foldoc.org/module
> * http://foldoc.org/library
> * http://foldoc.org/plugin
>
> As noted by XRevan86, modules are not necessarily non-essential.
> As we will keep the modules directory in GS root [therefore, near to
> plugins/], it is evidenced the difference between both.
>
> This is a simple yet fundamental structural change. It doesn't change
> functionality but makes clearer the way we understand GNU social's
> internals.
2.
> [CORE] Refactor Plugin API to Module API
Maybe we should refactor core plugins to stay in a different directory, to better give the idea that they aren't mere plugins.
For the effects of this RFC, and until a better name is proposed, I'll name such core-plugins of modules (to reflect specialized functionality).
The heart of this issue is that I can't understand why the core plugins have been created... Why has this functionality been extracted from core to separate plugins? (@MMN-o)
Another thing that confuses me is:
I think that we now have four options:
About ActivityModeration: This one is listed as core but all the core-code related to notice elimination was not ported to the plugin, contrary to what was done with the Favorite plugin.
For reference (raised by rozzin):
rozzin: If you look at changes when FavoritePlugin became a thing, for example... a lot of stuff got aggregated together more logically--the answer to "where is the code implementing favorites?" changed from "oh, all over the place..." to "in plugins/Favorite".
rozzin:
XRevan86:
Given that both directories (plugins and modules) would be in GNU social root, and "modules are not necessarily non-essential", it's maybe better to go with modules, as core-plugins might not be "as lower-level" as the other lib/ resources.
Relevant commits:
4cee29ab5caf318484001.
2.