On 20 January 2011 03:46, Larry Garfield <larry@xxxxxxxxxxxxxxxx> wrote:
> Does that make it clearer what I'm trying to do?
Some ideas. I've no idea if any of them are any good.
1 - All plugins implement a self-registration mechanism.
A analogy to this in the Windows world would be an ActiveX component.
All ActiveX components implement a function which is callable by a
component registration program (regsvr32.exe). During installation of
the app, the component registration process detects the registration
function and calls it to register the component. The function provides
all the data required for registration.
So, something like ...
/**
* Register plugin
*
* @return pluginRegistration
*/
final static public function abstractBasePlugin::registerPlugin(){
// Create and populate a pluginRegistration object.
// This would contain the interfaces implemented, the classes from
which the get_called_class() extends along with the hierarchy of the
interfaces and classes.
}
for example, would allow any class that extends abstractBasePlugin, to
be able to provide all the details about its class and interface
hierarchy.
Rather than just dropping files onto the server and hoping things all
work, all plugins must be "installed". This installation procedure
would then build the index at installation time for each plugin. Add
to this an unregister mechanism for those dead plugins (or for plugins
being upgraded) ...
If plugins are in constant development, the index needs to be updated
when the plugin is ready. Forcing an installation procedure would
certainly help here I think as only the current plugin needs to be
analysed and only once.
I'd probably also add details about the author of the plugin, so in
the event that the plugin is deleted (see auto tuning below), the
alerting system could inform the developer or whatever you think is
appropriate.
2 - Code protection.
Rather than leaving the source code as is, the installation process
could PHAR archive the files before placing it in the appropriate
place. That way, the include file wouldn't be editable in the live
environment ... maybe not good for the developers, but for users,
installed plugins can't be edited (easily) and therefore the index
should be consistent.
3 - Auto tuning.
I would probably add a small amount of realtime tuning to the indexer
in the event that a plugin is missing (someone deleted the file). The
lack of the file sends an appropriate email alert detailing the
missing file and indicates any orphaned subclasses and then tags the
index to exclude the missing class from that point onwards. All
dependent subclasses would also have to be tagged to exclude them from
the index. If the pluginRegistration content includes contact details,
you can include these in the alert.
4 - Plugin Inheritence.
During installation, if a plugin extends another plugin, you could
either throw an alert of some sort or have a mechanism that says the
parent class is non-callable. If nothing else, you could at least
report it and tell the developers that they need to sort this out.
Again, the developer may be able to provide details of this in the
pluginRegistration content (bool $parentCallable = true). Obviously,
multiple extensions could report different values for parentCallable,
so there would need to be some sort of guidelines and the installer
should enforce them.
The main thrust of this is that doing a static analysis is going to be
expensive and really you only need to analyse the file once and an
"installation" procedure would provide that time. It would be a step
that is familiar with many users (at least desktop user). And I think
it isn't too onerous on the developers. They only have to populate a
single object and extend from a single abstract class (or class that
has already extended from the abstract plugin class).
I hope these ideas help in some way.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
