Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Terminology for third-party modules is confusing #12186

Open
babolivier opened this issue Mar 9, 2022 · 5 comments
Open

Terminology for third-party modules is confusing #12186

babolivier opened this issue Mar 9, 2022 · 5 comments
Labels
A-Docs things relating to the documentation A-Modules Module API: https://matrix-org.github.io/synapse/latest/modules/index.html T-Other Questions, user support, anything else.

Comments

@babolivier
Copy link
Contributor

Currently we have a module system (or interface) where modules can register callbacks and use module API methods, which are different things. It feels like we keep confusing them, for example calling a module callback a module API (which is even more confusing because it technically is an API but just isn't a method of the ModuleApi class).

We need to figure out a better terminology.

@richvdh
Copy link
Member

richvdh commented Mar 9, 2022

so to be clear, the problem isn't with the word "module", it's about which direction the call is made (module -> synapse or synapse -> module)?

Intuitively, the difference seems fairly clear to me (synapse exposes an API which modules can use. Modules do not expose an API; rather they register callbacks via the module API). But perhaps I'm missing some subtlety? Do you have specific examples of the confusion?

(I'd argue the word "module" is confusing, given that Python attaches a particular meaning to that word. "Plug-in" might be better. But renaming it now might be harder work than is justified.)

@DMRobertson
Copy link
Contributor

(I'd argue the word "module" is confusing, given that Python attaches a particular meaning to that word. "Plug-in" might be better. But renaming it now might be harder work than is justified.)

I've had this objection to the term "module" since day one.

@babolivier
Copy link
Contributor Author

babolivier commented Mar 9, 2022

so to be clear, the problem isn't with the word "module", it's about which direction the call is made (module -> synapse or synapse -> module)?

It's about the words we use to name different parts of Synapse's module system (eg we sometimes refer to Synapse's module "interface" which isn't the same as the module "API", callbacks are technically part of Synapse's overall module API, just not of the ModuleApi class, etc).

Intuitively, the difference seems fairly clear to me (synapse exposes an API which modules can use. Modules do not expose an API; rather they register callbacks via the module API). But perhaps I'm missing some subtlety? Do you have specific examples of the confusion?

#12028 is the most recent example I've seen (I've renamed it for clarity). In general, I think I've had to correct people at least 50% of the time (probably more) because they're talking about "the module API" to refer to callbacks.

(I'd argue the word "module" is confusing, given that Python attaches a particular meaning to that word. "Plug-in" might be better. But renaming it now might be harder work than is justified.)

Yeah I wholly agree with you on this.

@richvdh
Copy link
Member

richvdh commented Mar 9, 2022

#12028 is the most recent example I've seen (I've renamed it for clarity). In general, I think I've had to correct people at least 50% of the time (probably more) because they're talking about "the module API" to refer to callbacks.

mmmhmm. I'm not sure that changing our terminology is the right solution to people wanting to use words to mean what they want them to mean, rather than what everyone else expects them to mean (or, indeed, is going to solve that problem at all).

image

It feels to me like this particular case might be a hangover from when you did actually need to implement a given API in your module - the terminology has stuck, even though that's no longer the case. Again, I don't think that changing how we refer to these things is going to change the fact that people will still use old terminology.

@babolivier
Copy link
Contributor Author

babolivier commented Mar 9, 2022

I'm not sure that changing our terminology is the right solution to people wanting to use words to mean what they want them to mean, rather than what everyone else expects them to mean (or, indeed, is going to solve that problem at all).

To me it feels like "what everyone expects them to mean" in this case is callbacks being part of the module API (which they aren't in our definition because imo we have a weird definition of what the module API is). I very much feel like we're the ones wanting to use words to mean what we want them to mean rather than what people expect them to mean.

It feels to me like this particular case might be a hangover from when you did actually need to implement a given API in your module - the terminology has stuck, even though that's no longer the case. Again, I don't think that changing how we refer to these things is going to change the fact that people will still use old terminology.

I wouldn't qualify it as legacy terminology (also because we've never used the term "module API" to mean the methods implemented inside a module afaict). To me callbacks that implement the interfaces described in the Synapse documentation are very much part of what I would otherwise call a module API - except for some reason we have decided to only call one bit of that interface "API".

@H-Shay H-Shay added A-Docs things relating to the documentation T-Other Questions, user support, anything else. labels Mar 10, 2022
@MadLittleMods MadLittleMods added the A-Modules Module API: https://matrix-org.github.io/synapse/latest/modules/index.html label Apr 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Docs things relating to the documentation A-Modules Module API: https://matrix-org.github.io/synapse/latest/modules/index.html T-Other Questions, user support, anything else.
Projects
None yet
Development

No branches or pull requests

5 participants