[wp-hackers] Plugin dependency checking

[Mike Schinkel]

"Stephen Rider" <wp-hackers at striderweb.com> wrote:
>>> The same plugin appearing in more than one place will
>>> confuse the heck out of users.
>>
>> While I like your sub-plugin model, will it confuse users if two (2)  
>> different plugins use the same sub-plugin?  I know you are thinking  
>> of plugins specifically made for another plugin but someone could  
>> easily choose to implement the same interface so they could have  
>> ready-made add-ins for their own plugin.
>
> Could you give me an example, because seriously I can't think of any.   
> Again note the distinction between dependent plugins and sub-plugins.

Sure I can give an example and one I think is highly likely.

Let's say the fine folks who are offering WP e-Commerce decided to create payment processor sub-plugins; one for PayPal, one for Google Checkout, etc. etc.  I in my opportunistic wisdom decide to create my own ecommerce solution targeted at video cartoon characters with blogs on WordPress which I choose to call "WP Super Mario Cart" (oblivious to the obvious trademark lawsuits that will be hurled at me.) But rather than worry about implementing all those tedious payment processing modules I just implement the same interface that WP e-Commerce chose to implement. Presto bango, I now have a bunch of dependent sub-plugins that will work for my new shopping cart.

> If I make a "Spam Karma ReCaptcha" sub-plugin with "Spam Karma" 
> as the master, I can't imagine that ever being *also* a sub plugin 
> for some other plugin.

All tongue-in-cheek aside I do very much see wanting to share payment processor plugins, probably more likely than two plugins using the same anti-spam plugin (but you never know.) One pearl I learned from someone much wiser than me was that while finding a needle in a haystack may be hard, it's practically impossible to prove that a needle does not exist in that haystack (i.e. you can't prove a negative.)  Even though, I can imagine that another plugin might want to use your Recaptcha sub-plugin. After all, that's one of the things that makes open-source so vibrant and valuable; i.e. the ability to directly reuse what someone else has previously made available for use in a different context.

Backing into someone else's successful extension model is a savvy business move, look how many years it worked for Compaq on the hardware side. So I guess what I'm saying is I don't see the difference between multi-dependent plugins and single dependent sub-plugins except for the fact that at the moment the latter has one on plugin for which it depends whereas the former currently has many.

But I don't think this is a deal killer for the admin UI, just something to consider.  Maybe the approach is to list those sub-plugins underneath both of the plugins on which they are applicable.

However as I write this is occurs to me that your concept of "dependent plugins" and "sub-plugins" is really just the concept of "interfaces" like from Java, .NET, and PHP5. 

   http://java.sun.com/docs/books/tutorial/java/concepts/interface.html
   http://php.net/manual/en/language.oop5.interfaces.php

Your sub-plugins "implement" an interface albeit a defacto one and one that is higher level than built into Java or PHP5 (Java & PHP5 know nothing of WordPress "hooks", for example.) Any plugin that depends on another plugin probably a defacto interface. Note that the interface can be "out-of-band", for example the sub-plugin could share options with the master plugin and never actually call any of it's functions, though that's not all that likely I don't think.

This interface concept is extremely powerful. From Sun's page:

"For example, imagine a futuristic society where computer-controlled robotic cars transport passengers through city streets without a human operator. Automobile manufacturers write software (Java, of course) that operates the automobile—stop, start, accelerate, turn left, and so forth. Another industrial group, electronic guidance instrument manufacturers, make computer systems that receive GPS (Global Positioning System) position data and wireless transmission of traffic conditions and use that information to drive the car. 

The auto manufacturers must publish an industry-standard interface that spells out in detail what methods can be invoked to make the car move (any car, from any manufacturer). The guidance manufacturers can then write software that invokes the methods described in the interface to command the car. Neither industrial group needs to know how the other group's software is implemented. In fact, each group considers its software highly proprietary and reserves the right to modify it at any time, as long as it continues to adhere to the published interface."

So having the idea of what I call a "Well-known Interface" is really useful even if it's not a formal interface. A well-known interface encourages reuse and solution growth. WordPress core's "hook" system is really a well-known interface, so is the Thesis theme's set of hooks.

If you already knew all this about interfaces, forgive me. Some people on wp-hackers have a deep computer science background and others first learned to program in order to modify WordPress and since I don't know who knows what I figured I'd inject a bit of this background.

I'm now thinking it would be really useful if we were to create an WP_Interface() class to formally recognize this concept as an OPTION for those who are implementing plugins that use dependent & sub-plugins. A WP_Interface() would define everything about how a plugin would and should be used by a dependent & sub-plugin even if some of that definition were simply prose. It would be part documentation, part validation and possibly part implementation.  

For example, upon plugin activation WordPress could validate sub-plugins against their defined WP_Interface if such an interface exists.  Hell, WordPress could validate all plugins against a WP_Interface("WordPress","2.9") if we agree to define it:

One of the big benefits of such an interface would be documentation (WOW!): 

   $wpi = New WP_Interface("WordPress","2.9");
   $wpi->print();

The other benefit would be validation:

   $wpi = New WP_Interface("Spam Karma","1.0");
   if (!$wpi->validate("spam-karma-recaptcha")) 
      echo "Sorry: this version of Spam Karma Recaptcha is not compatible with this version of Spam Karma.";

Validation would be HUGELY beneficial. If could allow us to disable non-conforming plugins during an upgrade and even make it possible to determine if there will be problems prior to an upgrade. WP_Interface() would go a long way towards making larger companies and agencies more comfortable with using WordPress because over time it would increase the robustness of the WordPress platform.

Again, I stress that what I'm proposing would be OPTIONAL in all cases, but opting for it would make it easier for people who want to implement an interface and it would make it so we could validate plugins against that interface. It would also typically only be used during activation and not on each page load so it wouldn't impact site performance except marginally upon activation. I'd be happy to work on this if others see it has value.  I'd want to collaborate on it with a least a few others, possible via a Google group (so as not to flood this list with discussions.)

Wrapping up by coming back to your concept of "dependent plugins" vs. "sub-plugins" I really don't think we should make any such distinction. I think t he only difference should be the fact one has code that uses the other or OPTIONALLY they define the relationship using a potential WP_Interface().  As for the admin UI I do agree that it would be nice to have a way to display those that are generally only there to be supportive of another plugin in a tree view up that plugin, but that should be determined by WordPress inspecting the two plugins not by anything defining a plugin as a "master" and another as a "slave." IMO, anyway.

-Mike Schinkel
Custom Wordpress Plugins
http://mikeschinkel.com/custom-wordpress-plugins

P.S. I think I now need to go back and re-read the entire thread because I hadn't paid close enough attention to see how (in)compatible it is with the WP_Interface() concept.