Very simple plugins subsystem

I like the approach here - we get an editable/versionable file, it will be writeable from the UI for people who don't want to hand edit it, it has the potential to be more performant than the current system although we need to verify how that will look in practice.

@chx's #4, I already have a patch at #987768: [PP-1] Optimize variable caching which means that rarely used variables will not be loaded for the vast majority of requests, and which tries to lessen some of the impact of variable_set(). The scope of that patch is very limited because it's primarily intended as something that can be potentially backported to D7 and D6 Pressflow, but it comes out of seeing many, many problems from the current system on real sites both in terms of memory usage and contention on the variables themselves.

There are a few cases (which to a large extent are a mis-use of the variable system but we don't have anything better right now) where this is a real issue - both rarely used variables like user settings, and frequently updated variables like cache clears, css/js aggregates, or whichever contrib module this week decided calling variable_set() on every request was a good idea. Replacing the system needs to either deal with those issues, or happen alongside other initiatives to clear those up.

Subscribe.

.

I've not gone over this patch with a fully fine toothed comb, so these comments are preliminary and in no particular order.

- The plugin system here looks like very early versions of the handlers stuff I was working on, before it got renamed Butler. :-) I am tentatively in favor, with two concerns:

1) This only maps to class names directly using an array, which makes it out of reach for most pluggable use cases. It would only be useful for very low-level things, and only by people who edit PHP config files.

2) I am unclear how we'd extend this system to handle the 50 other things we want a unified plugin system to do. Mostly I don't see how configuration and context information could be injected, and without a clear path forward I'm worried about us coding into a dead-end. (That said, it is a step up from where Queue is right now.)

- I am overall very much in favor of configuration data moving predominantly to a human-editable file. My concern is that doing so in a way that is both secure and not a huge PITA for users to edit (due to file permission issues) is really really hard, and we'd have to solve that first to make it worthwhile. I don't know if what's listed here would solve that; I don't see how, but it is after midnight.

- I do not like that it looks like there's still a dependency between variable_X() and setting_X(). It seems like we'd want to make them fully independent and then gradually eliminate usage of variable_X() in favor of setting_X(), and then drop the old variable system entirely. Adding more inter-related systems solves nothing. Unless I'm completely missing the goal here, but it seems like a "variable system TNG" patch, which I support in the general sense. (See previous note about it being after midnight.) Edit: Looks like Damien was suggesting the same thing from chx's comments in #6.

- As chx and I have discussed before, I am fully in agreement with the goal of "all queries happen in pluggable classes" for largely the same reasons he mentions, but also for general code cleanliness as it helps us to separate business logic code from data management code, which should be separate things. I don't know if in practice we'd be able to achieve that goal, but I believe we should strive for it.

- We would definitely need to examine the performance implications here. If it's break-even or better, that is good enough for me.

It's now too late for me to think more about it. :-) For now, +0.7 subscribe.

It would only be useful for very low-level things, and only by people who edit PHP config files.

chx is going to add a UI for this. The idea is you can either change settings from the UI and have them written to, or hand edit.

While it's good to separate data and business logic, most systems I've seen that swap in different data storage often want to change business logic as well to take advantage - for example memcache has major changes from the database cache.inc since it needs to account for very different feature sets. I think that's something which may have to happen within the pluggable subsystems themselves via convention, not necessarily at the level of what's pluggable. But there might be some in-between areas too.

Subscribey-scribe

"The drop is always moving" doesn't mean that going down a too-limited path doesn't make life difficult later, especially given core's haphazard at best development schedule. That's no excuse for not planning ahead. That is a meta-discussion, though. :-)

catch: Like most concepts, business/data separation is a great theory that frequently has gray areas in practice. That doesn't mean we shouldn't still try to push in that direction as much as possible anyway; the benefits of doing so are well understood.

sub

submariniscribing

FWIW, this is the issue discussed during the "configuration" core conversation at DC Chicago (IOW, "subscribing")

From core conversation, sounds like we need perhaps a way to figure out how to find cache/DB settings early in bootstrap, and maybe a larger file containing all the user settings.

After reading through both the patch and this issue, I have a few points I'd like to make.

1.) The "plugin" system here seems rather limited in it's exposure to the community at large. Essentially this is insufficient for the "plugin" system we need, so naming as the plugin system lends it a sense of finality that I think is false, and misleading. We need to be considering what the proper abstraction for a plugin utility is going to look like and start there. There are dozens of other places in core where plugin tools have been proposed and would be useful, so it seems problematic to eat the namespace without actually solving the problem.

2.) Some of your solutions here are very similar to rather larger scope solutions David Strauss had discussed at Drupalcon. He had discussed a whole hog replacement for the existing variable system, and I think it's relevant to this discussion.

Bottom line: Looks compelling, we should probably focus on plugins in core early in the cycle so that we don't have half a dozen independent plugin utilities floating around when we get ready to release.

Eclipse

sub

"The drop is always moving" doesn't mean that going down a too-limited path doesn't make life difficult later, especially given core's haphazard at best development schedule. That's no excuse for not planning ahead.

Amen. We have some really quite concrete plans, per our last discussion on sprint day at dcchi, for "early-stage" stuff that would look like this. I would rather wait for those than put this system in then have to rip it out later, along with whatever other systems have come to rely on it.

Looking for the concrete plans to become code quickly :-)

subscribe

subscribe

Marking as duplicate of #1497366: Introduce Plugin System to Core.