Proposal: replace the plugin loader with the service manager

[weierophinney]

Hey, all --

Per the subject, I'd like to discuss replacing the plugin broker +
plugin class locator system with the ServiceManager.

Currently, the Zend\Loader\Broker + Zend\Loader\PluginClassLocator
accomplishes the following:

 * PluginClassLocator handles resolution of a (short) plugin name to a
   fully qualified class name.

 * Broker composes a PluginClassLocator. Internally, it acts as a
   combination factory + validator + registry:

   * Given a plugin name and optionally some options, it looks up the
     class name via the PluginClassLocator, and creates a new instance
     of the plugin, with the provided options.

   * Once an instance is acquired, it validates it to see if it is
     suitable for the current context. As an example, the broker in
     Zend\Filter would check that the plugin implements FilterInterface.

   * Once a valid instance is known, it registers it internally, so that
     on next request, it may re-use the instance.

   * Ability to register specific instances with the broker (bypassing
     the creational facilities).

These capabilities/features are a subset of what the ServiceManager
currently offers. At this time, we even allow composing a ServiceManager
(more specifically, a ServiceLocatorInterface) into the Broker, which
allows retrieving plugins via the SM instead of creating them directly.
A quick breakdown shows:

 * PluginClassLocator is similar to the facilities of aliasing in the
   ServiceManager

 * The SM allows creating instances via a variety of means, including
   invokables, factories, and more.

 * The SM allows "initializers", which can act on or inspect an instance
   after it has been created. These can be used to validate the
   instance,if desired.

 * The SM acts as a registry.
 
 * You can register instances directly (setService()).
 
 * Ability to "peer" service manager instances -- meaning the SM
   instance can look in peers for a matching instance.

My thought was: let's get rid of the Broker+PluginClassLocator system.
To my thinking, we get the following benefits:

 * One less API to learn; re-use what will be a _very_ well-known API
   throughout the framework.

 * Reduce the number of classes needed for components needing plugins.
   Right now, you typically need both a Loader and a Broker class
   per-component.

I've done a proof-of-concept, using the Zend\Filter component as an
example:

    https://github.com/weierophinney/zf2/compare/feature/service-manager-as-plugin-broker

After writing this, I ran the FilterChain tests, and they simply worked
out of the box -- proving that in terms of external API, very little
changes. (Most people actually don't interact a ton with the broker
right now, based on some informal polling).

The main things to look at in the above link are the
AbstractPluginManager, which emulates most of what the combination of
Broker+PluginClassLocator did previously, and the FilterPluginManager,
which is a specific instance. The amount of code for the
FilterPluginManager is roughly similar to what we had before, but it's
all in a single class, making it much easier to understand what filters
are available, and what constitutes a valid filter.

I'd like to move forward with this for beta5 -- it should only take a
few hours to retrofit the various components in the framework that
currently use the broker.

What comments do you have? Please share them on the mailing list, and
during the IRC meeting tomorrow.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[mattcockayne]

looks good and makes a lot of sense to reuse the ServiceManager.

would be interesting to see if any performance gains are to be had as well.

On Wed, Jun 20, 2012 at 3:08 AM, Matthew Weier O'Phinney <[hidden email]> wrote:

Hey, all --

Per the subject, I'd like to discuss replacing the plugin broker +
plugin class locator system with the ServiceManager.

Currently, the Zend\Loader\Broker + Zend\Loader\PluginClassLocator
accomplishes the following:

 * PluginClassLocator handles resolution of a (short) plugin name to a
  fully qualified class name.

 * Broker composes a PluginClassLocator. Internally, it acts as a
  combination factory + validator + registry:

  * Given a plugin name and optionally some options, it looks up the
    class name via the PluginClassLocator, and creates a new instance
    of the plugin, with the provided options.

  * Once an instance is acquired, it validates it to see if it is
    suitable for the current context. As an example, the broker in
    Zend\Filter would check that the plugin implements FilterInterface.

  * Once a valid instance is known, it registers it internally, so that
    on next request, it may re-use the instance.

  * Ability to register specific instances with the broker (bypassing
    the creational facilities).

These capabilities/features are a subset of what the ServiceManager
currently offers. At this time, we even allow composing a ServiceManager
(more specifically, a ServiceLocatorInterface) into the Broker, which
allows retrieving plugins via the SM instead of creating them directly.
A quick breakdown shows:

 * PluginClassLocator is similar to the facilities of aliasing in the
  ServiceManager

 * The SM allows creating instances via a variety of means, including
  invokables, factories, and more.

 * The SM allows "initializers", which can act on or inspect an instance
  after it has been created. These can be used to validate the
  instance,if desired.

 * The SM acts as a registry.

 * You can register instances directly (setService()).

 * Ability to "peer" service manager instances -- meaning the SM
  instance can look in peers for a matching instance.

My thought was: let's get rid of the Broker+PluginClassLocator system.
To my thinking, we get the following benefits:

 * One less API to learn; re-use what will be a _very_ well-known API
  throughout the framework.

 * Reduce the number of classes needed for components needing plugins.
  Right now, you typically need both a Loader and a Broker class
  per-component.

I've done a proof-of-concept, using the Zend\Filter component as an
example:

   https://github.com/weierophinney/zf2/compare/feature/service-manager-as-plugin-broker

After writing this, I ran the FilterChain tests, and they simply worked
out of the box -- proving that in terms of external API, very little
changes. (Most people actually don't interact a ton with the broker
right now, based on some informal polling).

The main things to look at in the above link are the
AbstractPluginManager, which emulates most of what the combination of
Broker+PluginClassLocator did previously, and the FilterPluginManager,
which is a specific instance. The amount of code for the
FilterPluginManager is roughly similar to what we had before, but it's
all in a single class, making it much easier to understand what filters
are available, and what constitutes a valid filter.

I'd like to move forward with this for beta5 -- it should only take a
few hours to retrofit the various components in the framework that
currently use the broker.

What comments do you have? Please share them on the mailing list, and
during the IRC meeting tomorrow.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[Sascha-Oliver Prolic]

2012/6/20 Matthew Weier O'Phinney <[hidden email]>:

> Hey, all --
>
> Per the subject, I'd like to discuss replacing the plugin broker +
> plugin class locator system with the ServiceManager.
>
> Currently, the Zend\Loader\Broker + Zend\Loader\PluginClassLocator
> accomplishes the following:
>
>  * PluginClassLocator handles resolution of a (short) plugin name to a
>   fully qualified class name.
>
>  * Broker composes a PluginClassLocator. Internally, it acts as a
>   combination factory + validator + registry:
>
>   * Given a plugin name and optionally some options, it looks up the
>     class name via the PluginClassLocator, and creates a new instance
>     of the plugin, with the provided options.
>
>   * Once an instance is acquired, it validates it to see if it is
>     suitable for the current context. As an example, the broker in
>     Zend\Filter would check that the plugin implements FilterInterface.
>
>   * Once a valid instance is known, it registers it internally, so that
>     on next request, it may re-use the instance.
>
>   * Ability to register specific instances with the broker (bypassing
>     the creational facilities).
>
> These capabilities/features are a subset of what the ServiceManager
> currently offers. At this time, we even allow composing a ServiceManager
> (more specifically, a ServiceLocatorInterface) into the Broker, which
> allows retrieving plugins via the SM instead of creating them directly.
> A quick breakdown shows:
>
>  * PluginClassLocator is similar to the facilities of aliasing in the
>   ServiceManager
>
>  * The SM allows creating instances via a variety of means, including
>   invokables, factories, and more.
>
>  * The SM allows "initializers", which can act on or inspect an instance
>   after it has been created. These can be used to validate the
>   instance,if desired.
>
>  * The SM acts as a registry.
>
>  * You can register instances directly (setService()).
>
>  * Ability to "peer" service manager instances -- meaning the SM
>   instance can look in peers for a matching instance.
>
> My thought was: let's get rid of the Broker+PluginClassLocator system.
> To my thinking, we get the following benefits:
>
>  * One less API to learn; re-use what will be a _very_ well-known API
>   throughout the framework.
>
>  * Reduce the number of classes needed for components needing plugins.
>   Right now, you typically need both a Loader and a Broker class
>   per-component.
>
> I've done a proof-of-concept, using the Zend\Filter component as an
> example:
>
>    https://github.com/weierophinney/zf2/compare/feature/service-manager-as-plugin-broker
>
> After writing this, I ran the FilterChain tests, and they simply worked
> out of the box -- proving that in terms of external API, very little
> changes. (Most people actually don't interact a ton with the broker
> right now, based on some informal polling).
>
> The main things to look at in the above link are the
> AbstractPluginManager, which emulates most of what the combination of
> Broker+PluginClassLocator did previously, and the FilterPluginManager,
> which is a specific instance. The amount of code for the
> FilterPluginManager is roughly similar to what we had before, but it's
> all in a single class, making it much easier to understand what filters
> are available, and what constitutes a valid filter.
>
> I'd like to move forward with this for beta5 -- it should only take a
> few hours to retrofit the various components in the framework that
> currently use the broker.
>
> What comments do you have? Please share them on the mailing list, and
> during the IRC meeting tomorrow.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

+1 for Service Manager replacing PluginClassLocator + Broker !

--
Sascha-Oliver Prolic

[Marco Pivetta]

Makes a lot of sense. The ServiceLocatorInterface is much (much!) clearer than what the Broker implementations currently do, and also, those have been buggy lately and continuously losing functionality that is delegated more and more to the SM.
+1!

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 20 June 2012 11:14, Sascha-Oliver Prolic <[hidden email]> wrote:

2012/6/20 Matthew Weier O'Phinney <[hidden email]>:

> Hey, all --
>
> Per the subject, I'd like to discuss replacing the plugin broker +
> plugin class locator system with the ServiceManager.
>
> Currently, the Zend\Loader\Broker + Zend\Loader\PluginClassLocator
> accomplishes the following:
>
>  * PluginClassLocator handles resolution of a (short) plugin name to a
>   fully qualified class name.
>
>  * Broker composes a PluginClassLocator. Internally, it acts as a
>   combination factory + validator + registry:
>
>   * Given a plugin name and optionally some options, it looks up the
>     class name via the PluginClassLocator, and creates a new instance
>     of the plugin, with the provided options.
>
>   * Once an instance is acquired, it validates it to see if it is
>     suitable for the current context. As an example, the broker in
>     Zend\Filter would check that the plugin implements FilterInterface.
>
>   * Once a valid instance is known, it registers it internally, so that
>     on next request, it may re-use the instance.
>
>   * Ability to register specific instances with the broker (bypassing
>     the creational facilities).
>
> These capabilities/features are a subset of what the ServiceManager
> currently offers. At this time, we even allow composing a ServiceManager
> (more specifically, a ServiceLocatorInterface) into the Broker, which
> allows retrieving plugins via the SM instead of creating them directly.
> A quick breakdown shows:
>
>  * PluginClassLocator is similar to the facilities of aliasing in the
>   ServiceManager
>
>  * The SM allows creating instances via a variety of means, including
>   invokables, factories, and more.
>
>  * The SM allows "initializers", which can act on or inspect an instance
>   after it has been created. These can be used to validate the
>   instance,if desired.
>
>  * The SM acts as a registry.
>
>  * You can register instances directly (setService()).
>
>  * Ability to "peer" service manager instances -- meaning the SM
>   instance can look in peers for a matching instance.
>
> My thought was: let's get rid of the Broker+PluginClassLocator system.
> To my thinking, we get the following benefits:
>
>  * One less API to learn; re-use what will be a _very_ well-known API
>   throughout the framework.
>
>  * Reduce the number of classes needed for components needing plugins.
>   Right now, you typically need both a Loader and a Broker class
>   per-component.
>
> I've done a proof-of-concept, using the Zend\Filter component as an
> example:
>
>    https://github.com/weierophinney/zf2/compare/feature/service-manager-as-plugin-broker
>
> After writing this, I ran the FilterChain tests, and they simply worked
> out of the box -- proving that in terms of external API, very little
> changes. (Most people actually don't interact a ton with the broker
> right now, based on some informal polling).
>
> The main things to look at in the above link are the
> AbstractPluginManager, which emulates most of what the combination of
> Broker+PluginClassLocator did previously, and the FilterPluginManager,
> which is a specific instance. The amount of code for the
> FilterPluginManager is roughly similar to what we had before, but it's
> all in a single class, making it much easier to understand what filters
> are available, and what constitutes a valid filter.
>
> I'd like to move forward with this for beta5 -- it should only take a
> few hours to retrofit the various components in the framework that
> currently use the broker.
>
> What comments do you have? Please share them on the mailing list, and
> during the IRC meeting tomorrow.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

+1 for Service Manager replacing PluginClassLocator + Broker !

--
Sascha-Oliver Prolic

[Walter Tamboer]

I'm not sure if I can make the meeting tonight so count a +1 for me as well. It's a change that is understandable and makes sense.
 

---

From: [hidden email]
Date: Wed, 20 Jun 2012 11:36:37 +0200
To: [hidden email]
CC: [hidden email]
Subject: Re: [zf-contributors] Proposal: replace the plugin loader with the service manager

Makes a lot of sense. The ServiceLocatorInterface is much (much!) clearer than what the Broker implementations currently do, and also, those have been buggy lately and continuously losing functionality that is delegated more and more to the SM.
+1!

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 20 June 2012 11:14, Sascha-Oliver Prolic <[hidden email]> wrote:

2012/6/20 Matthew Weier O'Phinney <[hidden email]>:

> Hey, all --
>
> Per the subject, I'd like to discuss replacing the plugin broker +
> plugin class locator system with the ServiceManager.
>
> Currently, the Zend\Loader\Broker + Zend\Loader\PluginClassLocator
> accomplishes the following:
>
>  * PluginClassLocator handles resolution of a (short) plugin name to a
>   fully qualified class name.
>
>  * Broker composes a PluginClassLocator. Internally, it acts as a
>   combination factory + validator + registry:
>
>   * Given a plugin name and optionally some options, it looks up the
>     class name via the PluginClassLocator, and creates a new instance
>     of the plugin, with the provided options.
>
>   * Once an instance is acquired, it validates it to see if it is
>     suitable for the current context. As an example, the broker in
>     Zend\Filter would check that the plugin implements FilterInterface.
>
>   * Once a valid instance is known, it registers it internally, so that
>     on next request, it may re-use the instance.
>
>   * Ability to register specific instances with the broker (bypassing
>     the creational facilities).
>
> These capabilities/features are a subset of what the ServiceManager
> currently offers. At this time, we even allow composing a ServiceManager
> (more specifically, a ServiceLocatorInterface) into the Broker, which
> allows retrieving plugins via the SM instead of creating them directly.
> A quick breakdown shows:
>
>  * PluginClassLocator is similar to the facilities of aliasing in the
>   ServiceManager
>
>  * The SM allows creating instances via a variety of means, including
>   invokables, factories, and more.
>
>  * The SM allows "initializers", which can act on or inspect an instance
>   after it has been created. These can be used to validate the
>   instance,if desired.
>
>  * The SM acts as a registry.
>
>  * You can register instances directly (setService()).
>
>  * Ability to "peer" service manager instances -- meaning the SM
>   instance can look in peers for a matching instance.
>
> My thought was: let's get rid of the Broker+PluginClassLocator system.
> To my thinking, we get the following benefits:
>
>  * One less API to learn; re-use what will be a _very_ well-known API
>   throughout the framework.
>
>  * Reduce the number of classes needed for components needing plugins.
>   Right now, you typically need both a Loader and a Broker class
>   per-component.
>
> I've done a proof-of-concept, using the Zend\Filter component as an
> example:
>
>    https://github.com/weierophinney/zf2/compare/feature/service-manager-as-plugin-broker
>
> After writing this, I ran the FilterChain tests, and they simply worked
> out of the box -- proving that in terms of external API, very little
> changes. (Most people actually don't interact a ton with the broker
> right now, based on some informal polling).
>
> The main things to look at in the above link are the
> AbstractPluginManager, which emulates most of what the combination of
> Broker+PluginClassLocator did previously, and the FilterPluginManager,
> which is a specific instance. The amount of code for the
> FilterPluginManager is roughly similar to what we had before, but it's
> all in a single class, making it much easier to understand what filters
> are available, and what constitutes a valid filter.
>
> I'd like to move forward with this for beta5 -- it should only take a
> few hours to retrofit the various components in the framework that
> currently use the broker.
>
> What comments do you have? Please share them on the mailing list, and
> during the IRC meeting tomorrow.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

+1 for Service Manager replacing PluginClassLocator + Broker !

--
Sascha-Oliver Prolic

[akrabat]

On 20 Jun 2012, at 03:08, Matthew Weier O'Phinney wrote:

> I'd like to move forward with this for beta5 -- it should only take a
> few hours to retrofit the various components in the framework that
> currently use the broker.

I'm in agreement too. Less confusing all round.

Regards,

Rob...

[Ryan Hutchison]

Daddy likes +1

On Wed, Jun 20, 2012 at 7:37 AM, Rob Allen <[hidden email]> wrote:

On 20 Jun 2012, at 03:08, Matthew Weier O'Phinney wrote:

> I'd like to move forward with this for beta5 -- it should only take a
> few hours to retrofit the various components in the framework that
> currently use the broker.

I'm in agreement too. Less confusing all round.

Regards,

Rob...