compared with
Current by Artur Bodera
on Aug 31, 2011 16:38.

(show comment)
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (23)

View Page History
Add agenda items for the meeting here, following the guidelines on the [IRC meeting homepage|IRC Meetings].
<p>Add agenda items for the meeting here, following the guidelines on the <ac:link><ri:page ri:content-title="IRC Meetings" /><ac:link-body>IRC meeting homepage</ac:link-body></ac:link>.</p>

h2. Modules
<h2>Modules</h2>
Kevin McArthur has raised on the mailing list architectural design goals:

* Discuss modular architecture goals.
** What is a module?
*** Module/Extension/Adapter/Implementation
*** Is a single class (i.e. Zend\Captcha\SomeAdapter) a module?
*** Should Zend MVC be a module?
*** Can a module live in {{Zend\}} namespace ?
*** Can modules extend core {{Zend\}} components (like a {{Zend\Db\Adapter}} implementation)
*** Can a ZF1-ported Zend component (unmaintained, less-frequently used, like Zend\Wildfire) be a module?
** How should modules be administered (drag+drop ftp, zend_tool, a UI, etc)
** Do modules need versioning? Strongly named assemblies?
** Can modules override other modules? (Including their resources like GIF/JPG/PHTML/etc?)
** Can modules override core components? (like Zend\Db, via DI or otherwise)
** Implications on caching/performance of design decisions.
** Eco-system. App-Store? Channels?
** Tightly coupled core? (Benefits of relying on Cache, Config, etc as hard interdependencies)
** Usage of a code-scanner and automagic compilation of modules into a runtime set vs explicit installation/deinstallation/upgrades.
** Creation of a Data layer analogous to the MVC layer, inclusion in 'standard distribution', but allow for independent use?
** Implications for VCS, packaging (phar?), configuration (dpkg-reconfigure? ui? config files?), etc.
<p>Kevin McArthur has raised on the mailing list architectural design goals:</p>

Rob Allen raised an [RFC on modules|RFC - ZF2 Modules]. We need to finalize requirements. In particular, the following have outstanding questions/issues:
<ul>
<li>Discuss modular architecture goals.
<ul>
<li>What is a module?
<ul>
<li>Module/Extension/Adapter/Implementation</li>
<li>Is a single class (i.e. Zend\Captcha\SomeAdapter) a module?</li>
<li>Should Zend MVC be a module?</li>
<li>Can a module live in <code>Zend</code> namespace ?</li>
<li>Can modules extend core <code>Zend</code> components (like a <code>Zend\Db\Adapter</code> implementation)</li>
<li>Can a ZF1-ported Zend component (unmaintained, less-frequently used, like Zend\Wildfire) be a module?</li>
</ul>
</li>
<li>How should modules be administered (drag+drop ftp, zend_tool, a UI, etc)</li>
<li>Do modules need versioning? Strongly named assemblies?</li>
<li>Can modules override other modules? (Including their resources like GIF/JPG/PHTML/etc?)</li>
<li>Can modules override core components? (like Zend\Db, via DI or otherwise)</li>
<li>Implications on caching/performance of design decisions.</li>
<li>Eco-system. App-Store? Channels?</li>
<li>Tightly coupled core? (Benefits of relying on Cache, Config, etc as hard interdependencies)</li>
<li>Usage of a code-scanner and automagic compilation of modules into a runtime set vs explicit installation/deinstallation/upgrades.</li>
<li>Creation of a Data layer analogous to the MVC layer, inclusion in 'standard distribution', but allow for independent use?</li>
<li>Implications for VCS, packaging (phar?), configuration (dpkg-reconfigure? ui? config files?), etc.</li>
</ul>
</li>
</ul>

* Should modules have configuration read by an installer, or simply a class following a specific interface that is invoked by the installer and/or at runtime?
** One possibility is to implement a concept of "imports" in Zend\Config, which would allow simply specifying a file to import under a given key in the configuration file. This could simplify installation, keep configuration discrete between modules, and allow for easy overrides via the master configuration file.
* How should module metadata be delivered? Suggestions include a plain text file (ala Pyrus), storing it in configuration, or delivering it via the module configuration class.
* Should a module contain a single namespace? or should the module _be_ the namespace? Should modules follow reverse-TLD format, or be project/vendor aliases? Should all classes in a module follow PSR-0 guidelines?
* What should installation look like?
** Will an "installer" script (and/or Zend\Tool resource) be necessary?
** Should we allow informing the application via adding a configuration line?
** Should we allow autodiscovery at runtime?

<p>Rob Allen raised an <ac:link><ri:page ri:content-title="RFC - ZF2 Modules" /><ac:link-body>RFC on modules</ac:link-body></ac:link>. We need to finalize requirements. In particular, the following have outstanding questions/issues:</p>

<ul>
<li>Should modules have configuration read by an installer, or simply a class following a specific interface that is invoked by the installer and/or at runtime?
<ul>
<li>One possibility is to implement a concept of &quot;imports&quot; in Zend\Config, which would allow simply specifying a file to import under a given key in the configuration file. This could simplify installation, keep configuration discrete between modules, and allow for easy overrides via the master configuration file.</li>
</ul>
</li>
<li>How should module metadata be delivered? Suggestions include a plain text file (ala Pyrus), storing it in configuration, or delivering it via the module configuration class.</li>
<li>Should a module contain a single namespace? or should the module <em>be</em> the namespace? Should modules follow reverse-TLD format, or be project/vendor aliases? Should all classes in a module follow PSR-0 guidelines?</li>
<li>What should installation look like?
<ul>
<li>Will an &quot;installer&quot; script (and/or Zend\Tool resource) be necessary?</li>
<li>Should we allow informing the application via adding a configuration line?</li>
<li>Should we allow autodiscovery at runtime?</li>
</ul>
</li>
</ul>


<p>These seem to be the primary issues still under discussion on the ML, and we should decide on a path forward.</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Modules - Should we discuss this?
|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>

h2. Distribution
<h2>Distribution</h2>

Matthew posted an [RFC on Distribution|RFC - What will the ZF2 distribution include?]. At this time, there's been a lot of discussion on the list, and we appear to be reaching consensus on the items. Matthew will update the RFC prior to the meeting, and we can discuss if there are any additional changes that need to be made.
<p>Matthew posted an <ac:link><ri:page ri:content-title="RFC - What will the ZF2 distribution include?" /><ac:link-body>RFC on Distribution</ac:link-body></ac:link>. At this time, there's been a lot of discussion on the list, and we appear to be reaching consensus on the items. Matthew will update the RFC prior to the meeting, and we can discuss if there are any additional changes that need to be made.</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Distribution - Should we discuss this?
|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>