Firestorm is a very interesting piece of software and the concept itself is worth exploring, but I’m not sure this is what I’m after.
@Phillipp I’m still relatively new to both Elixir and Phoenix but I don’t think a plugin system is something that would be hard to implement. No matter the language, I would design a production grade CMS to accept signed packages from the admin system with the optional override with a huge warning. Each package would have a standard format for installation, migration, upgrading, and deletion whether it be local or remote.
As for handling plugin compilation, I need to explore OTP more, but I don’t see why this would be a problem. Could you be more specific as to why you couldn’t use a newly installed plugin?
Related: Does hot code-swapping come for free?
You raise a good point about PHP. Maybe I’m just too naive to the drawbacks of Elixir + Phoenix, but I really don’t see the issue here. I’ll have to explore some strategies and will hopefully get back to you soon.
@shanesveller Discourse is certainly better than most if not all forum software but it’s not something I would wish to install and run myself. A conversation organizer might be a more accurate description of what I might attempt to build.
In my opinion, very few people need Docker, and I also don’t like the idea of downloading entire environments. Install Nix package manager, install it on an Arch machine, and call it a day.
Related: https://nixos.org/nixos/nix-pills/
I wasn’t aware of Firestorm being crowdfunded. Do you feel the team delivered or was it a pump-and-dump of dev that you normally see on Kickstarter?
@frigidcode With the latest updates to Elixir, Phoenix, and LiveView, do you think the effort of a fork is worth it? Sometimes re-inventing the wheel helps you understand the pain points that eventually lead to a better solution.
@Cochonours I’m not so sure about the idea of hooks. I understand that method is popular with Wordpress but I don’t like the concept of anything from anywhere being able to alter anything. I would try to keep it more consistent with concept of Phoenix pipelines if possible. Hopefully you would agree that a good plugin system wouldn’t require any code modifications outside of maybe a configuration file. Are you aware of lesser known alternatives to the hook-style system?
Although it sounds super cool to allow plugins to communicate with each other, I would consider this an anti-pattern. Unless you’re designing a set of plugins that need to communicate with each other, there’s no way this isn’t a debug nightmare. Do you know of a scenario where this would be considered a good idea?
One DB per-plugin doesn’t sound ideal to me. I’ve been a fan of database.schema.table
for a good decade or two. In your production grade applications, do you often need an entire database for a single feature? Normally you would only do this if the DB was shared with other applications and those applications existed before your requirements. I can certainly see why there might be headaches in terms of permissions. I’m not saying it’s the most practical thing to do, but you could probably have two different DB users, being a general CMS user, and a plugin CMS user. Basically the plugin CMS user wouldn’t be able to touch certain schemas or would have read-only access. I’m also not too worried about the setup and cleanup of a plugin because I would design a system that would only accept a single standard that addressed both migrations and table ownership. I would go as far as programmatically creating a new DB user for each plugin and lock that user into a schema created just for the plugin. The only real hurdle is being able to get the permissions correct and being reasonable about how to adjust them for a non-technical user.
A plugin being coded in a different language sounds like a nightmare to me but I’m open to new ideas if you have some candidates? You’re basically describing FFI from what I understand. If I were to take this route, all plugins would have to be written in this language. I would only build a system that supported a single language simply from a maintenance perspective.
Related: https://github.com/clojerl/clojerl
@OvermindDL1 A hook-based system might’ve worked for Discourse, but it’s also written in what I believe to be a less powerful language. I’m not sure what system I’m going to come up with or if it’s even going to be successful, but for sure I think we can do better than hooks and events.
@adrianrl I agree with you about DB performance. You also have to think about connection pools and I don’t think having a connection pool for an example of 20 plugin-specific DBs is going to be something I’m willing to do. Maybe there’s a good reason to do this?