GNU social

User Tools

Site Tools

Trace:
components:v2modules
no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.


—components:v2modules [2021/12/08 00:28] (current) – created - external edit 127.0.0.1
Line 1: Line 1:
 +**The introduction of Modules in V2**
  
 +This is an adapted transcription from a RFC issue concerning the implementation of Modules in GS v2.
 +
 +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).
 +
 +According to rozzin, and I think it was later confirmed by MMN-o: MMN-o had to extract this functionality from core to separate plugins because it was being hard of maintaining GNU social and his sanity at the same time with everything spread around in a spaghetti manner.
 +
 +Some apparent inconsistencies are:
 +
 +  * 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.
 +
 +Diogo presented four options:
 +
 +1. Move everything to actual plugins (hard-work, requires making everything actually dynamic);
 +2. Re-integrate all the core plugins into core (hard-work, means reverting everything - and would be stupid as it was surely extracted from core on the first place for a reason);
 +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 of this and do nothing (meh).
 +
 +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):
 +
 +  * 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.
 +
 +Note: includeals is Diogo's IRC nickname
 +
 +---
 +
 +Key commits of the resulting change from the above discussion:
 +
 +1. [[https://notabug.org/diogo/gnu-social/commit/c18f26145c2f800e5a98cae6988cef06be6877d3|c18f26145c]]
 +
 +> [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. [[https://notabug.org/diogo/gnu-social/commit/99fe3e5a52154a94b1199c2ff9d45098399f9009|99fe3e5a52]]
 +
 +> [CORE] Move plugin superclasses from /lib/ to /lib/modules/
 +
 +3. [[https://notabug.org/diogo/gnu-social/commit/20a6f1d4f4ad9ff3bf316004be9ca4eb9ffdfa71|20a6f1d4f4]]
 +
 +> [CORE] Plugin API now extends a new Module API
components/v2modules.txt · Last modified: by 127.0.0.1