![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
In previous Drupals we had a rough version of plugins -- you could load a cache plugin instead of cache.inc but that was all. The pluggability was on file level and it only existed for very few files. Drupal 7 introduced many more pluggable subsystems and now the pluggability happens on a class level (mostly). We can plug in sessions, cache, queue, field storage, password hashing... Crell is working on unifying these for quite some time now. And this is all good, however, for Drupal 8 I would like to see a lot more. I mentioned field storage already -- that's an install time decision because moving content from one storage to another is not trivial to say the least. If we have install time decisions on plugins then we could use the install system to compile files for us with the desired pieces swapped in. Edit: for example you could replace a function with an alternative implementation from a contrib instead of actually hacking the file. Updates are still easy just need a recompilation step -- thanks to the new upgrade manager that'd not be too hard either.
Also, this can happen on packaging time as well, so the ordinary user never needs to touch it. Yay for profile hosting on Drupal.org :) More, we can use PHP streams to include code from database! Which can lead to the same thing: pluggability on any level we want. I will write more why we want that, stay tuned!
Commenting on this Story is closed.
I'm not convinced that "compile-time" pluggability is worth much. It's really only useful if you're doing merge-to-one-huge-file type compiles of Drupal, which are (and should be) a rare edge case. That said, making more things cleanly pluggable is just good practice in general for many reasons. That it would enable such edge cases as this is one of the benefits, but there are many many more.
Actually, I just realized something else about the compile-to-one-file approach. That's only really viable if we don't need to manually load files, because we'd then need to remove the manual load (require_once et al) calls when merging into the one big file. PHP has a built-in mechanism to do that for us, however: Class autoloading. If we rely on autoload to load code for us, then making the class we want available before Drupal needs it (via compile-to-one-file or implementing it in C or whatever) neatly bypasses the explicit load and means we need to modify no other code to make it work. So it sounds like using OO for such pluggability would make the entire process easier. Hmmm...
I am talking of swapping pieces of a given file.
How would opcode caches react when you'd pull code from the database?
I think it would be a major performance setback.
APC can be configured to work with this.
oh noes, please forget about storing and loading code from the DB.
It's unmaintainable, not versioned, invisible, and overall totally unmanageable.
There are a couple of applications that allow this (f.e. vBulletin), and if you ever worked with them, then you know that you absolutely do NOT want that. Regardless of how dynamic, interesting, and funny the idea might be.
On development you would use file-based compilation and put it in a DB if you want on deploy. Also? This is just a blog and we are discussing :)
Not to mention how maintainable it will be will all the hacked plugins in place. Upgrading would be a nightmare.
I happen to be in agreement with "Anonymous." Having faced a few of those "nightmare" upgrades myself, I wouldn't wish them on anyone. Hacked plugins might be tempting in the short run, but in the long run they just aren't worth the risk.
You bring up some excellent points. Before working with Drupal, I spent about four years maintaining a C# based enterprise product that was very heavily metadata driven. Changing database tables meant hand-editing a 2 meg XML file named 'objectschema.xml' and only the fact that we were using a compiled language with a lot of built-in support for XML munching saved us from ourselves.
Trying to make a "Generic System-Building System" in any language is bound to end in tears. A language like PHP is one of the worst to attempt that in, as it lacks a lot of the baked in introspection and metadata management systems that are part of heavier languages with more presence in the enterprise.
In my mind, Drupal core's tendency towards 'abstract everything, provide a framework for everything, make everything metadata driven, commit to nothing' is actually a symptom of the Framework/Product tethering that we currently suffer from. There's strong, strong pressure to improve the core Drupal *product* but the only way to do that is to tailor it for a given use case. That's unacceptable, though, because it's also a framework that other, contradictory use cases rely on! And thus, the core product has to implement all of its tailored features in a very abstract fashion, with endless hooks and alterable structures in place so that people can strip away the functionality (or tweak it) if needed.
Although I try to fight the idea that 'smallcore' is about stripping stuff out of Drupal,the idea of allowing the core product to include one-off functionality if it needs it, rather than forcing that functionality into the framework, can lead to a smaller, lighter Drupal core. While the default Drupal 'Product' may get heavier with more UX work, more bundled functionality, and more tailoring, it needn't drag the framework along for the ride.
Here is my term paper, if you are interested.
Improved the documentation a bit, and fixed the nitpicks catch mentioned. Following DBTNG, I didn't add docblocks to the resetCache() and loadMultiple() methods as they are documented in the interface.
Now. Of course this makes the code flow a bit more complex. But I really think the benefits outweigh the disadvantages. The former being a consistent load API for all core entity types and the possiblity to completely replace them in contrib. And it would be a perfect fit for the handlers patch, sure. I know that I won't have the time to really work on the handlers patch (ie biometrico), but I will gladly convert this patch to use its API, should handlers get in.
And I think (read: fear) it is already a requirement for D7 to be released to make api.module able to parse class and interface doxygen. DBTNG already forces us to do so (try to look up the different fetch methods of a select query on api.drupal.org - good luck! See dedetização). So, this has to be addressed, anyways. Maybe we need some "api.module sunday" or something.
Also note that all public facing API functions are completely unchanged. The changes here are purely internal. node_load_multiple() et. al. and the related _load hooks are not changed at all, but now use the same API, instead of a different implementation each.
Edit: I still cannot reproduce the three fails in taxonomy vocabularies test. I get 100% passes here. Weird.
Edit 2: I do share chx's and sun's concerns. But I don't think that this code is especially hard, and I think that they can be solved by improving documentation, and that they shouldn't hold innovation and this patch up. That's my opinion, at least for my project (brindes canetas). And I agree with sun that if this gets in, it could make it easier to work on handlers by having another perfect use case in core.