Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="toc" />

<h2>Information</h2>

<ul>
<li>Date: 14 September 2011, 17:00-19:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2011-09-14+Meeting+Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Artur Bodera (nickname Thinkscape)</li>
</ul>

<h2>Summary</h2>

<h3>Component Configuation</h3>

<p>This discussion was informed by three RFCs:</p>

<ul>
<li><ac:link><ri:page ri:content-title="RFC - Object instantiation and configuration" /><ac:link-body>Object instantiation and configuration</ac:link-body></ac:link></li>
<li><ac:link><ri:page ri:content-title="RFC - better configuration for components" /><ac:link-body>Better configuration for components</ac:link-body></ac:link></li>
<li><ac:link><ri:page ri:content-title="RFC - Comparison of config styles" /><ac:link-body>Comparison of config styles</ac:link-body></ac:link></li>
</ul>

<p>The consensus was to use the following within ZF2:</p>

<ul>
<li>Hard dependencies should be explicitly included in the constructor signature. A dependency is considered <em>required</em> if no sane default is possible (such as an unconfigured object instance).</li>
<li>Optional dependencies would be contained in a "parameter container", and the constructor would have expect that container as an optional argument.</li>
<li>Hard dependencies that have <em>sane defaults</em> could be injected via setter injection, removing the need for a constructor argument.</li>
</ul>

<p>Paddy provided a <ac:link><ri:page ri:content-title="gist detailing the basis for a parameter container" /><ac:link-body>https://github.com/padraic/zf2/blob/1dafd898d68b479feedb78b1ea2634c9854747fd/library/Zend/Stdlib/Configuration.php</ac:link-body></ac:link>.</p>

<p>Post-meeting, some concern was raised about using the names "Config" or "Configuration", as they could cause confusion with the "Zend\Config" component; consensus is that "Options" is a better term.</p>

<h3>The fate of "extra" components</h3>

<p>This discussion was informed by the <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>.</p>

<p>As we had decided during the last meeting that components not considered part of the standard distribution (i.e., outside the "Core", "DB and Data Formats", "Security, "i18n/l10n", and "MVC" categories) could be omitted from development tasks, the question now is: should we keep these in the repository, or move them out?</p>

<p>Consensus is that we keep them in; however, the following action items need to be taken:</p>

<ul>
<li>Unfinished components in these "other" categories should be marked with a class-level annotation indicating "incomplete", "unstable" or similar; alternately, all components we <em>will</em> ship will receive an annotation indicating that status (e.g., "stable").</li>
<li>Test case classes for unfinished components will receive either the "@group disable" annotation, or we will add a new PHPUnit group and add that group to the "exclude" list of the phpunit.xml. This will help us focus on the testability of components we'll ship.</li>
<li>The manual.xml.in file will be edited to comment out documentation of components we do not ship.</li>
<li>When packaging, we will omit all components marked "incomplete" (or whatever annotation we decide on)</li>
<li>Developers interested in using or refactoring those components can grab them from the git repository.</li>
</ul>

<h3>Module Manager goals</h3>

<p>This part of the discussion was informed by the <ac:link><ri:page ri:content-title="RFC - ZF2 Modules" /><ac:link-body>Modules RFC</ac:link-body></ac:link>, with specific questions outlined directly in the <ac:link><ri:page ri:content-title="2011-09-14+Meeting+Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link>.</p>

<p>Paddy took over direction of the discussion at this point, trying to tally votes for each item.</p>

<ol>
<li><strong>Handle multiple installation methods.</strong> No naysayers.</li>
<li><strong>Handle multiple installation sources.</strong> No naysayers.</li>
<li><strong>Handle two installation styles (local and shared).</strong> This was heavily discussed, but the idea is that modules could be installed either directly in the project, or in a "shared" location (e.g., a PEAR directory). This is actually already supported by the current Module Manager prototype – you simply point it at directories, and it queries the Module class under each.</li>
<li><strong>Perform on-demand loading of modules.</strong> This is already possible in the current prototype, and all agreed this is acceptable. The only clarification is that this should be possible both at run-time, as well as from things like a CLI tool.</li>
<li><strong>Handle discovering, registering, loading, and merging of... lots of stuff.</strong> General agreement is that the list is reasonable (though some items on the list may go the way of the dodo with the current prototype). The solution should be flexible enough to allow the module to do whatever it may need to do; the module manager does not necessarily need to know every type of task possible.</li>
<li><strong>Manage static assets.</strong> General consensus is that this is desirable, but few people can visualize how it might happen; prototypes and/or proposals are needed.</li>
<li><strong>Handle modules registry.</strong> This had not been discussed prior to the meeting, and there was confusion by some as to what was under discussion. Thinkscape proposed static "isLoaded()", "isAvailable()", "isInstalled()" style methods for querying what modules can be used. Matthew was uncertain whether these were really necessary; much of the information could be provided via configuration, DI discovery, and/or class_exists(). No agreement reached.</li>
<li><strong>Handle simple module dependencies.</strong> All votes appeared to be negative on this, with the idea that this is for an installer utility to handle.</li>
<li><strong>Respond to registry queries.</strong> See point 7.</li>
</ol>

<p>One potential point of contention was the term "installation". Nobody disagreed with having a Module Manager query modules, but there was some worry that we're talking about a package management system. General consensus is that module packages could be distributed and installed via an existing mechanism such as Pyrus or PEAR, which would manage the versioning and installation tasks (defined by ralphschindler as "putting code in the proper place"). Application installation – the process of informing the application of the module and what it provides – would be the Module Manager's job, however.</p>

<p>Another point was whether shared-dir installs should be supported; rdohms agreed to bring this up on the list.</p>

<p>A note was made that the current "ModuleCollection" class should be renamed "ModuleManager".</p>

<p>Finally, the main point heard over and over again during discussion of these items is that the "Module" class in each module should ideally be the only requirement for modules, as we can perform any discovery necessary from it.</p>

<h3>Directory structure for packaging and arranging modules' files</h3>

<p>This part of the discussion was informed by the <ac:link><ri:page ri:content-title="RFC - ZF2 Modules" /><ac:link-body>Modules RFC</ac:link-body></ac:link>.</p>

<p>The consensus is that we should not enforce a directory structure other than a "Module" class in the module's namespace found in the "Module.php" file in the module's root directory. This common entry point can then be used by a Module Manager to get information on autoloading, DI definitions, configuration, etc.</p>

<p>That said, we also had consensus that we should <em>recommend</em> a directory structure. The following structure had wide approval:</p>

<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
<pre style="border: 1px solid darkgray;padding: 0.5em;">
modules/
SpinDoctor/
Module.php
autoload_classmap.php
autoload_function.php
autoload_register.php
configs/
spin-doctor.ini
routes.ini
public/
images/
css/
spin-doctor.css
js/
spin-doctor.js
src/
SpinDoctor/
Controller/
SpinDoctorController.php
DiscJockeyController.php
Form/
Request.php
tests/
bootstrap.php
phpunit.xml
SpinDoctor/
Controller/
SpinDoctorControllerTest.php
DiscJockeyControllerTest.php
</pre>
]]></ac:plain-text-body></ac:macro>

<p>Basically, the idea is to separate files by type (configuration from PHP source from unit tests from public assets). We would also recommend that the source tree follow PSR-0 naming guidelines.</p>

<p>Undecided is how modules should be named – whether they should have a Vendor prefix, etc. This can be discussed later.</p>

<h2>Log</h2>

<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
<style>
pre.log {
white-space: -moz-pre-wrap; /* Mozilla, supported since 1999 */
white-space: -pre-wrap; /* Opera 4 - 6 */
white-space: -o-pre-wrap; /* Opera 7 */
white-space: pre-wrap; /* CSS3 - Text module (Candidate Recommendation) http://www.w3.org/TR/css3-text/#white-space */
word-wrap: break-word; /* IE 5.5+ */
border: 1px solid darkgray;
padding: 0.5em;
}
</style>
<pre class="log">
Sep 14 17:00:38 <rdohms> kick it!
Sep 14 17:00:48 »» Thinkscape kicks it
Sep 14 17:00:52 <guilhermeblanco> \o/
Sep 14 17:01:05 »» rizza headbangs.
Sep 14 17:01:09 <Thinkscape> Hello everyone!
Sep 14 17:01:09 »» rdohms waits for it to kick back
Sep 14 17:01:14 <PadraicB> rizza, ouch
Sep 14 17:01:40 <weierophinney> So, Thinkscape is MODERATOR
Sep 14 17:01:42 <ezimuel> hey guys
Sep 14 17:01:50 <weierophinney> That means HE HAS AUTHORITY TO END DISCUSSIONS
Sep 14 17:01:51 <weierophinney>
Sep 14 17:01:53 <rdohms> weierophinney: +1
Sep 14 17:02:03 <Thinkscape> We have estimated 1h to discuss 4 topics today
Sep 14 17:02:13 <rizza> Thinkscape: With such great power comes… great power. That's all. Good luck!
Sep 14 17:02:22 <Thinkscape> remember: Nothing is definite, it's only a discussion to bring us closer to the goal.
Sep 14 17:02:25 <weierophinney> .. and we can spill over up to 30 minutes. But let's try not to.
Sep 14 17:02:26 <EvanDotPro> estimated being the key word
Sep 14 17:02:33 <Thinkscape> Here's the agenda:
Sep 14 17:02:43 <Thinkscape> 1. A brainstorm on: Best configuration style for ZF2 components
Sep 14 17:03:06 <Thinkscape> 2. A quick talk and decision on what to do with "extra components"
Sep 14 17:03:23 <Thinkscape> 3. A more convoluted discussion on Module Manager and goals of modules as such.
Sep 14 17:03:41 <Thinkscape> 4. Related to 3. - Directory structure for packaging and arranging modules' files
Sep 14 17:03:49 <Thinkscape> Let's start with 1.
Sep 14 17:04:01 <Thinkscape> Here is the comparison http://framework.zend.com/wiki/display/ZFDEV2/Comparison+of+config+styles
Sep 14 17:04:08 <Thinkscape> First question: have we missed anything?
Sep 14 17:04:15 <Thinkscape> do you know any good config styles not mentioned there?
Sep 14 17:04:28 <Thinkscape> What can we look at? What are some good patterns for that ?
Sep 14 17:04:39 <Thinkscape> Or what would you change in these 4 styles we've outlined.
Sep 14 17:04:41 <Thinkscape> GO!
Sep 14 17:04:56 <weierophinney> PadraicB, I believe you're opinionated on this topic?
Sep 14 17:05:01 <weierophinney> and ralphschindler as well...?
Sep 14 17:05:43 <weierophinney> I personally think the last style works best for our goals. The only question is what to do about hard dependencies for which sane defaults can be lazily determined.
Sep 14 17:05:47 <weierophinney> PadraicB, any thoughts?
Sep 14 17:05:58 <PadraicB> Well, my idea is pretty much the same as Thinkscape's
Sep 14 17:05:58 <weierophinney> or anybody else?
Sep 14 17:06:03 <weierophinney> PadraicB, which is?

Sep 14 17:06:24 <PadraicB> We use a Configuration object to replace the typical array parameter
Sep 14 17:06:37 <ralphschindler> i'm still undecided on having dependencies in the constructor
Sep 14 17:06:56 <weierophinney> PadraicB, right... but what about hard dependencies and/or dependencies with defaults?
Sep 14 17:08:19 <ralphschindler> does this mean options are public parameters?
Sep 14 17:08:22 <PadraicB> Defaults can be set on a config object. Hard deps can be passed into constructor on the basis they represent a fundamental strategy (e.g. using a Socket adapter for Zend\Http\Client <- fundamental strategy for HTTP requires)

Sep 14 17:08:54 <weierophinney> PadraicB, that's actually a good example of where a "sane default" might be implemented.
Sep 14 17:08:56 <Thinkscape> ralphschindler: options CAN be public parameters on config-obj if they are scalar and not-validated.
Sep 14 17:09:03 <weierophinney> Perhaps a factory in that particular case?
Sep 14 17:09:09 <Thinkscape> ralphschindler: otherwise, set/getters.
Sep 14 17:09:13 <PadraicB> ralphschindler, optionally. Though the explicit method is via setter/getter (public props would route back to those)
Sep 14 17:09:17 <PadraicB> https://github.com/padraic/zf2/blob/1dafd898d68b479feedb78b1ea2634c9854747fd/library/Zend/Stdlib/Configuration.php
Sep 14 17:09:36 <PadraicB> As a rough prototype for a base class
Sep 14 17:09:39 <Thinkscape> is there any 5th option you guys are considering ? PadraicB mentioned discussion on "interface injection". Can you elaborate?
Sep 14 17:10:34 <ralphschindler> the general principle there is that an interface marks the methods that fulfill a dependency injection point, and that they are moved out of the constructor (constructor injection)
Sep 14 17:10:36 <weierophinney> Thinkscape, that would be via DI, and ralphschindler can discuss.
Sep 14 17:11:12 <weierophinney> PadraicB, that looks good.
Sep 14 17:11:14 <ralphschindler> it seems as though we favor the ability to automatically load sane dependencies (Defaults)
Sep 14 17:11:17 <weierophinney> (the base class)
Sep 14 17:11:43 <ralphschindler> currently new Zend\Di loads a default RuntimeDefinition and default InstanceManager, for example
Sep 14 17:12:02 <weierophinney> So, to me, I'm hearing Option 4 of the comparison, with the potential for dealing with "sane defaults" via setter injection?
Sep 14 17:12:02 <ezimuel> PadraicB, very nice!
Sep 14 17:12:15 <Spabby> +1
Sep 14 17:13:01 <PadraicB> ralphschindler, makes sense - so these would not enter via the constructor then? Optionally over-ridable via a setter instead?
Sep 14 17:13:14 <ralphschindler> PadraicB: correct
Sep 14 17:13:34 <ralphschindler> and tools like Di container would know dependencies based off whats listed in the interface

Sep 14 17:14:11 <benjamin-gb> hi
Sep 14 17:14:17 <PadraicB> ralphschindler, so what's left (if anything) to go into the constructor?
Sep 14 17:14:27 <ralphschindler> just the Parameter object
Sep 14 17:14:31 <ralphschindler> optionally of course
Sep 14 17:14:58 <PadraicB> Well, I don't see any problem with that (better vote before I think about it now )
Sep 14 17:15:11 <ralphschindler> it keeps the usage story very simple, and a consistent out of box experience
Sep 14 17:15:55 <weierophinney> ralphschindler, would you expect that we'd always use setter injection over constructor injection?
Sep 14 17:16:13 <weierophinney> or only for objects for which we can select sane defaults?
Sep 14 17:17:05 <Thinkscape> Ok. How about w refactor a few components to show it off?
Sep 14 17:17:21 <tgodar> Trying to catch up on ethis topic... does that mean an object has a 'ready' state or something then...? How do you know the 'hard dependencies' are satisfied?
Sep 14 17:17:21 <ralphschindler> always prefer it for component classes (the main class)
Sep 14 17:17:51 <ralphschindler> but relax the requirement for other classes in the component?
Sep 14 17:18:04 <Thinkscape> tgodar: hard dependencies are satisfied during construction. otherwise you get fatal error.
Sep 14 17:18:10 <ralphschindler> so that at least Zend\View\View's usage is consistent with Zend\Di\Di ?
Sep 14 17:18:20 <weierophinney> you mean z
Sep 14 17:18:21 <Thinkscape> tgodar: __construct(Adapter $adapter) — you need a valid $adapter to make ti work.
Sep 14 17:18:28 <tgodar> gotcha
Sep 14 17:18:30 <weierophinney> Zend\View\PhpRenderer, right, ralphschindler?
Sep 14 17:18:45 <weierophinney> zomg, are we reaching consensus?
Sep 14 17:18:52 <Thinkscape> Ok, we have to move on.
Sep 14 17:19:02 <Thinkscape> Let's refactor a few components
Sep 14 17:19:11 <ralphschindler> i think when it comes to component configuration, i think we have a concencus
Sep 14 17:19:15 <Thinkscape> could we see i.e. HTTP refactored with that ?
Sep 14 17:19:28 <ralphschindler> Thinkscape: i think so
Sep 14 17:19:35 <Thinkscape> We'll put it to final review on ML...
Sep 14 17:19:38 <Thinkscape> Great!
Sep 14 17:19:39 <ralphschindler> Zend\Di is already exactly that
Sep 14 17:19:45 <Thinkscape> now
Sep 14 17:19:48 <Thinkscape> "A quick talk and decision on what to do with "extra components"
Sep 14 17:19:59 <Thinkscape> Extra components are those, which are not inside "CORE"
Sep 14 17:20:00 <Thinkscape> or MVC
Sep 14 17:20:15 <Thinkscape> For example: services
Sep 14 17:20:20 <Thinkscape> Dojo
Sep 14 17:20:25 <intiilapa> Thinkscape: extra components or not in standard distribution?
Sep 14 17:20:26 <Thinkscape> Infocard
Sep 14 17:20:27 <Thinkscape> and such
Sep 14 17:20:40 <PadraicB> Assign all there issues to Artur Bodera?
Sep 14 17:20:44 <PadraicB>
Sep 14 17:20:45 <intiilapa> standard distribution != core + MVC
Sep 14 17:20:48 <Thinkscape> Wait...
Sep 14 17:20:59 <Thinkscape> there is a standard distribution – this will contain something we call "standard"
Sep 14 17:21:02 <Thinkscape> as bogus as this is
Sep 14 17:21:08 <Thinkscape> also - we'll have COMPLETE/full distribution
Sep 14 17:21:10 <weierophinney> Thinkscape, less editorial.
Sep 14 17:21:21 <Thinkscape> But there is an alternative
Sep 14 17:21:34 <Thinkscape> we can ship something we call "standard distribution" that will be thin, by definition.
Sep 14 17:21:35 <weierophinney> intiilapa, we're referring to this RFC, btw: http://framework.zend.com/wiki/pages/viewpage.action?pageId=43745438
Sep 14 17:21:57 <Thinkscape> And package all the rest of Zend* namespace into downloadable packages for on-demand installation
Sep 14 17:22:07 <weierophinney> standard distribution = "Core" + "DB and Data Formats" + "Security" + "I18n/L10n" + "MVC"
Sep 14 17:22:11 <Thinkscape> including everything under Zend\Sevice*
Sep 14 17:22:51 <PadraicB> Thinkscape: PEAR/Pyrus/Composer <- whichever is selected that is the plan (except for standard being too thin)
Sep 14 17:22:53 <weierophinney> Right, so the question is really: do we keep them under library/ for now, or push them into a different hierarchy?
Sep 14 17:22:54 <PadraicB> I think
Sep 14 17:23:02 <Thinkscape> Basically - each service is a package you can fetch on-demand with: #zf install service-gdata or #zf install service-recaptcha
Sep 14 17:23:04 <weierophinney> PadraicB, agreed.
Sep 14 17:23:07 <intiilapa> maybe strange to have captacha out of form / mvc
Sep 14 17:23:29 <intiilapa> -a
Sep 14 17:23:35 <PadraicB> We need to bear in mind the categories are metatags, presumably, for whichever package installer is used.
Sep 14 17:23:44 <weierophinney> intiilapa, I'd argue in that case that the Captcha form element moves into the unsupported area.
Sep 14 17:23:59 <rdohms> so.. is ZF standard a folder with application, library, etc like the symofny standard.. or is it just the ZF files, as is today?
Sep 14 17:24:18 <intiilapa> weierophinney: ok, but it's a commun feature on the web now
Sep 14 17:24:32 <weierophinney> rdohms, like it is today. There would be tooling to create an application skeleton.
Sep 14 17:24:44 <weierophinney> intiilapa, outside the scope of this discussion.
Sep 14 17:24:45 <intiilapa> rdohms: symfony standard comes with some bundles
Sep 14 17:24:54 <rdohms> so where does "library" fit in?
Sep 14 17:25:14 <PadraicB> rdohms, library is what it always been - a collection of classes.
Sep 14 17:25:21 <weierophinney> rdohms, um, that's where code is installed...
Sep 14 17:25:54 <tgodar> so the reasoning is because these will not be completely refactored in time... or to divide on components that are more 'optional'
Sep 14 17:25:55 <PadraicB> MVC architecture can be generated to use the library (Symfony just let you download both at once...sort of)
Sep 14 17:25:57 <weierophinney> Back to the point... do we keep those items not yet complete (as in not refactored, not fixed, etc.) in the main tree, or move them out?
Sep 14 17:26:02 <tgodar> what is the real objective?
Sep 14 17:26:07 <rdohms> ut where is it? its not in the download package if as you said its as is today, today we download the ZF folder and its namespace... i.e Zend/... not library/Zend .. library/etc..
Sep 14 17:26:40 <intiilapa> library is for vendor codes like Zend Framework and/or Symfony2
Sep 14 17:26:43 <PadraicB> weierophinney, we keep them in the same tree I would say. We can drop them from distributions, at a future point, if they are clearly lost causes
Sep 14 17:26:51 <intiilapa> library is a folder of the app
Sep 14 17:27:10 <weierophinney> rdohms, where are you downloading from? because all packages on framework.zend.com have a library directory
Sep 14 17:27:24 <EvanDotPro> we can just maintain a list on the wiki of which is/isn't ready for release.
Sep 14 17:27:27 <weierophinney> PadraicB, okay – so keep them in, but have the packaging script omit them?
Sep 14 17:27:29 <mascker> weierophinney: agree. Keep them in the same tree
Sep 14 17:27:36 <PadraicB> weierophinney, exactly.
Sep 14 17:27:45 <ezimuel> same tree for me
Sep 14 17:28:00 <intiilapa> EvanDotPro: how months before release?
Sep 14 17:28:10 <weierophinney> kk, so we simply need to maintain that info.
Sep 14 17:28:16 <PadraicB> If we move them out and stigmatise them, they'll never be fixed anyway IMO. Might as well delete them at that point.
Sep 14 17:28:16 <Akrabat> I'd prefer them out of the tree personally, so that it's clear what's 'done'
Sep 14 17:28:19 <EvanDotPro> intiilapa: we can establish a more detailed process for it at a later time.
Sep 14 17:28:23 <weierophinney> intiilapa, I'd argue we prune them at RC time?
Sep 14 17:28:48 <hhatfield> with them in the same tree, is there a way to show that they most likely will be undergoing refactoring and are candidates for BC breaks?
Sep 14 17:29:03 <Akrabat> though presumably, we'll have a system when building docs that ignores the "not done" stuff
Sep 14 17:29:09 <weierophinney> hey, all, there's another aspect to this: testing
Sep 14 17:29:15 <PadraicB> hhatfield, everything up for BC breaks until it enters a stable distributed release
Sep 14 17:29:23 <EvanDotPro> oh good point weierophinney
Sep 14 17:29:29 <weierophinney> Although we can address that with phpunit.xml + "@group disable"
Sep 14 17:29:36 <Thinkscape> Look. If we use any half-decent packaging system, we can use @tags. this includes stability tags. Components that are less stable could still be in the main repository to download "at own risk". Better than deleting them or ignoring during packaging.
Sep 14 17:29:39 <Akrabat> weierophinney: testing is essentially same issue as doc creation
Sep 14 17:29:52 »» rdohms realizes how long its been since he downloaded ZF not using the svn
Sep 14 17:29:52 <weierophinney> Perhaps somebody could go through and add an "@group disable" annotation to all components that we've marked as "other" for now?
Sep 14 17:29:53 <intiilapa> weierophinney: depend if we release when we finish the components of std distrib or we drop some components to release because we miss time
Sep 14 17:29:57 <rdohms> ok nevermind me...
Sep 14 17:30:16 <PadraicB> Thinkscape, possibly - though PEAR has encouraged using betas/devs - people may never check this.
Sep 14 17:30:18 <weierophinney> Thinkscape, good point – we can use annotations when creating packages, too.
Sep 14 17:30:53 <Thinkscape> We should use that . My reasoning is: if we put them into repository, someone might pick them up and fix ... maybe not tomorrow, but a few months from now.
Sep 14 17:31:04 <Thinkscape> But they will be marked accordingly ...
Sep 14 17:31:27 <weierophinney> Thinkscape, yes, and they can remove those annotations in their own branch as they begin testing.
Sep 14 17:31:40 <weierophinney> as for the manual, simply comment out sections we don't want to build.
Sep 14 17:31:41 <Thinkscape> PadraicB: pear has the stability filter. So by default it will not download something marked as "alpha" or "broken-beyond-repair".
Sep 14 17:31:43 <weierophinney> That's easy enough.
Sep 14 17:31:52 <weierophinney> Thinkscape, correct.
Sep 14 17:31:53 <rdohms> weierophinney: building the suite with xml and adding groups would solve the issues, we have that setup here, phpunit will scan fodlers and run what it finds, not there, no worries
Sep 14 17:32:03 <weierophinney> ralphschindler, yep.
Sep 14 17:32:13 <Akrabat> on the flip side, we'll get a lot of bug reports against stuff we know isn't 'good'
Sep 14 17:32:26 <Thinkscape> One more thing - what happens to bug tracking for those?
Sep 14 17:32:29 <Thinkscape> ZF2 Jira ?
Sep 14 17:32:35 <Thinkscape> what about other, new components ?
Sep 14 17:32:37 <PadraicB> Akrabat, and a lot of patches if people insist on fixing it - < upside
Sep 14 17:32:38 <weierophinney> Akrabat, potentially. But we can also prioritize those low... and those won't be in the actual release.
Sep 14 17:32:53 <Akrabat> PadraicB: I like optimism
Sep 14 17:33:05 <weierophinney> so, let me summarise:
Sep 14 17:33:18 <weierophinney> * Keep the "unstable", lower priority packages in the tree
Sep 14 17:33:34 <weierophinney> * Have an annotation in classes that will not be shipped (or, vice versa, those that will)
Sep 14 17:33:57 <weierophinney> * Mark tests for unshipped classes as "@group disable" or something simlilar that phpunit.xml knows to ignore
Sep 14 17:34:01 <PadraicB> Akrabat, reviewing 150 issues gave me cause for optimism. Broken stuff may be a lot better if we address their open issues over time.
Sep 14 17:34:09 <weierophinney> * Comment out items in the manual.xml.in we won't ship
Sep 14 17:34:17 <PadraicB> Not continually ignore them and leave them open for years...
Sep 14 17:34:18 <hhatfield> would a "full" install include the "unstable" packages? or do they have to explicitly be installed?
Sep 14 17:34:21 <weierophinney> Does that sound correct?
Sep 14 17:34:32 <weierophinney> hhatfield, would not be shipped or packaged.
Sep 14 17:34:34 <Thinkscape> weierophinney: please define "in the tree"
Sep 14 17:34:38 <PadraicB> weierophinney, yes
Sep 14 17:34:39 <Akrabat> The bit about commenting out in manual is really really important
Sep 14 17:34:47 <rdohms> weierophinney: yes... the test thing might need a bit more details and reseach but that is the gist of it
Sep 14 17:34:49 <PadraicB> hhatfield, no - they'd be omitted
Sep 14 17:34:49 <weierophinney> Thinkscape, under library/, tests/ etc. – the current repo structure.
Sep 14 17:35:12 <weierophinney> hhatfield, if you wanted them, you'd have to grab from git.
Sep 14 17:35:29 <tgodar> what Akrabat said, would need to make very clear to existing users moving to ZF2 what is excluded
Sep 14 17:35:46 <Thinkscape> * Unmaintained packages are not distributed with ZF2, but obtainable on-demand via selected distro. mechanism (pear/pyrus...)
Sep 14 17:35:56 <hhatfield> weierophinney: good. I think that would keep the bug report clutter down.
Sep 14 17:36:15 <PadraicB> Thinkscape, time?
Sep 14 17:36:26 <Thinkscape> Next one is huge
Sep 14 17:36:28 <Thinkscape> but important
Sep 14 17:36:39 <Thinkscape> MODULES
Sep 14 17:36:46 <Thinkscape> Short intro
Sep 14 17:36:47 <PadraicB> ZUNDLES
Sep 14 17:36:53 <Thinkscape> Modules are not what ZF1 modules are
Sep 14 17:37:04 <Thinkscape> Modules by current "draft" are packages
Sep 14 17:37:07 <weierophinney> Thinkscape, why? that involves extra packaging effort.
Sep 14 17:37:09 <Thinkscape> they can tie into MVC or not
Sep 14 17:37:14 <weierophinney> (referring to your last point above)
Sep 14 17:37:19 <weierophinney> You added that without discussion
Sep 14 17:37:20 <Thinkscape> wait up
Sep 14 17:37:37 <Thinkscape> They are a generalization of what ZF1 modules were.
Sep 14 17:37:39 <EvanDotPro> Okay, let's cover weierophinney quickly then circle back to modules.
Sep 14 17:37:52 <PadraicB> brb
Sep 14 17:37:53 <Thinkscape> There will be "modules" that are not related to mvc
Sep 14 17:37:53 <weierophinney> Thinkscape, basically, why would we package things we don't support?
Sep 14 17:37:54 <EvanDotPro> (once Thinkscape finishes his thought)
Sep 14 17:37:59 <weierophinney> Thinkscape, back up, please.
Sep 14 17:38:05 <weierophinney> You added an item that we didn't discuss!
Sep 14 17:38:13 <Thinkscape> ok
Sep 14 17:38:28 »» rdohms slams on the handbrake
Sep 14 17:38:52 <Thinkscape> If we don't know what modules are , how can we discuss module manager?
Sep 14 17:38:55 <weierophinney> 1) why would we package them? and (2) if we did, wouldn't we need a way of indicating its unstable?
Sep 14 17:38:57 <EvanDotPro> Thinkscape: weierophinney had suggested we just have unsupported components available via git, and skip packaging until they're considered "ready"
Sep 14 17:39:37 <weierophinney> I think that's the easiest course of action, and involves the least amount of confusion for users – if we package them, we'll get bug reports.
Sep 14 17:39:38 <intiilapa> I think we can't package a component with broken/skipped tests
Sep 14 17:39:43 <weierophinney> intiilapa, +1
Sep 14 17:40:10 <EvanDotPro> weierophinney: for (2), any packaging meachanism we use should support that, but I'm for not spending effort on packaging anything that's unsupported for now. IMO, others can set up a separate repository and package them if there's a need to be filled.
Sep 14 17:40:35 <Akrabat> I agree. "unstable" components shouldn't be packaged
Sep 14 17:40:38 <Thinkscape> The purpose of packaging half-working stuff is for other people to be able to obtain in.
Sep 14 17:40:50 <Thinkscape> Git is not a good choice
Sep 14 17:40:51 <rdohms> weierophinney: how bout providign a git repository and using something like symfony's bin/vendor .. it basically just downloads from that git repo
Sep 14 17:40:53 <weierophinney> Thinkscape, why not?
Sep 14 17:40:54 <Akrabat> if you want to use unstable, then you need the git as we want pull requests
Sep 14 17:40:55 <Thinkscape> Git is not a packagins mechanism.
Sep 14 17:41:15 <weierophinney> Thinkscape, agreed, but then, these are ready packages!
Sep 14 17:41:25 <rdohms> imho these do not need "packaging" they only need distribution
Sep 14 17:41:28 <Akrabat> we don't want "non-devs" using broken stuff and thinking that's how ZF2 rolls
Sep 14 17:41:34 <weierophinney> Akrabat, +1
Sep 14 17:41:42 <Spabby> Akrabat: +1
Sep 14 17:41:48 <weierophinney> rdohms, how would you accomplish distribution without packaging?
Sep 14 17:42:06 <Thinkscape> Let's say we have Service\Simpy that is outdated. if someone #zf install service-simpy a prompt appears: "This package in unstable (15 failed tests) do you still want to download it?"
Sep 14 17:42:10 <rdohms> weierophinney: define packaging
Sep 14 17:42:55 <rdohms> like Bundles in sf .. they don't need packaging.. just download and install
Sep 14 17:43:06 <intiilapa> we should improve the quality with continous integration behavior (build docs, php lint, all unit tests should be green, etc.)
Sep 14 17:43:07 <PadraicB> rdohms, packaging is a protocol describing a download source and a method of installing that source on a local filesystem
Sep 14 17:43:17 <PadraicB> Bundles are packages
Sep 14 17:43:22 <weierophinney> rdohms, bundles still need packaging; they simply have a mechanism for it.
Sep 14 17:43:24 <Spabby> Thinkscape: imho, if something is that unstable, it should not be available to install via the package service, you should need to manually grab it from the git repo
Sep 14 17:43:40 <weierophinney> Spabby, +1
Sep 14 17:43:55 <Thinkscape> rdohms: packaging = class files + other assets + a blob of metadata. distribution is irrelevant - you can extract it manually, or pyrus, or clone from git - all will be supported.
Sep 14 17:44:15 <Thinkscape> What is the threshold then ?
Sep 14 17:44:23 <rdohms> ok i can see my concepts were wrong, carry on
Sep 14 17:44:24 <Spabby> 0 failed tests
Sep 14 17:44:30 <PadraicB> Thinkscape, unstable = unfit for production. The only reason someone would want it, is to test/develop/improve - using git promotes PRs and collaboration in those cases
Sep 14 17:44:30 <Spabby> for a starting point
Sep 14 17:44:42 <Thinkscape> ok
Sep 14 17:44:51 <hhatfield> Spabby: how do we handle class dependencies in different parts of the tree?
Sep 14 17:45:04 <Thinkscape> Back to the subject - a ZF2 module is a package with classes and other files that talk to other modules and Zend* classes.
Sep 14 17:45:06 <rdohms> i think it needs 2 checks: 0 failing tests plus a human "itsready" from the responsible dev ...
Sep 14 17:45:14 <Thinkscape> Module manager is used to handle dependencies between those.
Sep 14 17:45:16 <rdohms> we can have 0 failing tests but partial funcionality
Sep 14 17:45:19 <PadraicB> hhatfield, via the packaging protocol (e.g. PEAR's deps resolver)
Sep 14 17:45:21 <rdohms> which is not good
Sep 14 17:45:32 <weierophinney> rdohms, we're all agreed at this point. Thinkscape has moved on.
Sep 14 17:45:33 <Akrabat> "stable" components are ones we're prepared to support and bug fix
Sep 14 17:45:42 <intiilapa> we should review all unit tests (a lot skipped or failed actualy)
Sep 14 17:46:01 <PadraicB> P.S. the Module Manager implements a Package Protocol (in a sense - need to differentiate between the two)
Sep 14 17:46:16 <intiilapa> PadraicB: +1
Sep 14 17:46:25 <Thinkscape> ---- guys Let's move on. The stability is a slippery topic. 0 failed tests == 0 tests? etc. We will see how it goes. Currently - broken stuff is not distrubuted but obtainable by other means.
Sep 14 17:46:29 <Thinkscape> now
Sep 14 17:46:31 <Thinkscape> module manager
Sep 14 17:46:31 <intiilapa> like phing implement pear package, pear2 package, and phar package
Sep 14 17:46:32 <Thinkscape> http://framework.zend.com/wiki/display/ZFDEV2/2011-09-14+Meeting+Agenda
Sep 14 17:46:32 »» rdohms is as lost as a blind man in a shootout
Sep 14 17:46:34 <Thinkscape> -----------
Sep 14 17:46:39 <EvanDotPro> Thinkscape: and the instatiation / configuration of them.
Sep 14 17:46:40 <Thinkscape> here is a shortlist of what it should be able to do
Sep 14 17:46:52 <PadraicB> rdohms
Sep 14 17:47:19 »» weierophinney waits for the list...
Sep 14 17:47:21 <Thinkscape> Please notice a few things – multiple distribution backends. ..
Sep 14 17:47:21 <EvanDotPro> s/instatiation/instantiation
Sep 14 17:47:32 <Thinkscape> and sources
Sep 14 17:47:35 <intiilapa> module manager must be aware of installation (install db, migration db, asset available, etc.)
Sep 14 17:47:56 <Thinkscape> A module can be as big as Magento or as small as a single db adapter for Zend\Db.
Sep 14 17:48:18 <intiilapa> Thinkscape: yes
Sep 14 17:48:38 <Thinkscape> Looking at that list — is there anything missing?
Sep 14 17:48:43 <tgodar> http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+ZF2+Modules
Sep 14 17:48:45 <Thinkscape> Is there anything, that should not be handled ?
Sep 14 17:49:09 <PadraicB> Thinkscape, yes...but...that assumes we package everything as a Module. As in all of ZF packaged as framework specific Modules. How do non-ZF apps utilise that (look at how Bundles have evolved...shudder)
Sep 14 17:49:29 <Thinkscape> – the list is at: http://framework.zend.com/wiki/display/ZFDEV2/2011-09-14+Meeting+Agenda - scroll to "Module Manager"
Sep 14 17:49:58 <Thinkscape> non-ZF apps can still use them
Sep 14 17:50:00 <Thinkscape> for example
Sep 14 17:50:06 <Thinkscape> classes are PSR0 compatible - you can autoload them
Sep 14 17:50:19 <Thinkscape> js/img/ etc assets are just files - you can copy them over or link
Sep 14 17:50:42 <weierophinney> PadraicB, basically, the Module Manager automates tasks that can otherwise be done manually
Sep 14 17:50:46 <intiilapa> Thinkscape: default loader is classmap + autotload PSR0?
Sep 14 17:51:02 <weierophinney> intiilapa, that's up to the developer.
Sep 14 17:51:02 <alextech> will the manager be also able to adjust the front controller routes in case need to access MVC of a module in ZF1 style? or is the /module/controller/action completely thrown out.
Sep 14 17:51:09 <weierophinney> intiilapa, there's a factory for that.
Sep 14 17:51:32 <Thinkscape> alextech: we want to have a both route override and extension ... and priorities
Sep 14 17:51:34 <ralphschindler> if we have a clear entry point, i don't see why we need to enforce a directory structure
Sep 14 17:51:49 <weierophinney> alextech, /module/controller/action is largely unnecessary. However, each module would have suggested routes, and you could then override them in the app config.
Sep 14 17:51:49 <Thinkscape> alextech: for example: if there are modules and sub-modules that override some behaviors of parent modules.
Sep 14 17:51:49 <EvanDotPro> ralphschindler: +1
Sep 14 17:51:53 <PadraicB> I got lost - what is the current topic?
Sep 14 17:51:59 <PadraicB> Directory struct?
Sep 14 17:52:04 <Thinkscape> PadraicB: Module Manager - what should it do?
Sep 14 17:52:05 <ralphschindler> module manager, yes
Sep 14 17:52:20 <PadraicB> Okay then. From the list...

Sep 14 17:52:35 <PadraicB> Handle multiple installatin methods. Anyone disagree?
Sep 14 17:52:54 <EvanDotPro> be careful here, since this topic will likely determine my workload over the coming weeks
Sep 14 17:53:00 <PadraicB> hehe
Sep 14 17:53:08 <PadraicB> Still waiting for -1s...
Sep 14 17:53:41 <ralphschindler> what are you addressing PadraicB (from the list?)
Sep 14 17:54:02 <Rvl> why not only app specific modules, otherwise I think there will be too much abstraction
Sep 14 17:54:06 <EvanDotPro> ralphschindler: #1 from the "Module Manager goals" on the meeting agenda
Sep 14 17:54:08 <PadraicB> 1st point under Module Manager goals http://framework.zend.com/wiki/display/ZFDEV2/2011-09-14+Meeting+Agenda
Sep 14 17:54:11 <ralphschindler> ok
Sep 14 17:54:32 <rdohms> +1
Sep 14 17:54:36 <EvanDotPro> Rvl: have you looked over my current module manager prototype?
Sep 14 17:54:51 <ralphschindler> is module manager a runtime component or a development time tool?
Sep 14 17:54:58 »» Thinkscape gives direct link: http://framework.zend.com/wiki/display/ZFDEV2/2011-09-14+Meeting+Agenda#2011-09-14MeetingAgenda-ModuleManagergoals
Sep 14 17:55:04 <PadraicB> Right, the silent majority are...silent. Assuming you all voted +1
Sep 14 17:55:12 <Thinkscape> ralphschindler: both
Sep 14 17:55:27 <weierophinney> ralphschindler, both, definitely
Sep 14 17:55:29 <PadraicB> Second point, Handle multiple installation sources? Anyone disagree
Sep 14 17:55:39 <Thinkscape> ralphschindler: if a module is "installed" by copying it over to the tree, then a Module Manager scanner have to be involved
Sep 14 17:55:42 <weierophinney> ralphschindler, the idea is that you can use it in your bootstrap, or you could invoke it frm a script.
Sep 14 17:55:43 <EvanDotPro> PadraicB: i'm +1, i think the installation method should be largely transparent to the module manager, so supporting multiple methods should be no problem.
Sep 14 17:55:47 <Thinkscape> ralphschindler: otherwise, it will be invoked from CLI or WebInstallator
Sep 14 17:55:56 <weierophinney> PadraicB, +1
Sep 14 17:56:17 <PadraicB> Any -1s?
Sep 14 17:56:26 <rdohms> PadraicB: +1 should read from a config file
Sep 14 17:56:39 <Rvl> EvanDotPro: I'm not up to date with the current state of it. Probably my topic was not ontopic
Sep 14 17:57:04 <PadraicB> Rvl, no worries - it's a complicated and busy topic in ZF2. Even I can't track all of it
Sep 14 17:57:13 <PadraicB> Assuming the silent majority assents...
Sep 14 17:57:24 <PadraicB> Third point, Handle two installation styles: "local installation" and "shared-dir installation"? Anyone disagree?
Sep 14 17:57:34 <ralphschindler> i think module sources and methods are largely non-factors as you're using 3rd party tools to transfer the code anyway
Sep 14 17:57:55 <ralphschindler> if we're talking about reinventing packaging/distribution mediums, I'm -1
Sep 14 17:57:55 <ezimuel> ralphschindler, +1
Sep 14 17:57:56 <EvanDotPro> +1 to the third point, my current prototype already supports this.
Sep 14 17:58:00 <PadraicB> ralphschindler, has a bearing later on the management tool though.
Sep 14 17:58:09 <Thinkscape> ralphschindler: +1 there will be helper tools though. For example #zf install X
Sep 14 17:58:16 <weierophinney> PadraicB, those make sense. The only one I'm unsure of is parallel versions on a shared install, but it sounds like that may be possible (according to ralphschindler)
Sep 14 17:58:37 <rdohms> PadraicB: -1 shared dir feels like its too personal
Sep 14 17:58:44 <ralphschindler> what is "shared dir" ?
Sep 14 17:58:48 <PadraicB> weierophinney, we can park it for now. If we support local installs - it can be figured out in time
Sep 14 17:58:53 <weierophinney> yep
Sep 14 17:59:07 <ralphschindler> like, multiple projects sharing modules?
Sep 14 17:59:09 <PadraicB> ralphschindler, like PEAR's main director /usr/share/php or whatever
Sep 14 17:59:11 <EvanDotPro> ralphschindler: correct
Sep 14 17:59:42 <ralphschindler> it seems as though this too is transparent to the module manager
Sep 14 17:59:43 <Thinkscape> ModManager is configurable - this means it will be up to the developer to decide per-app if it should use shared-dir modules, and which ones (or local modules)
Sep 14 17:59:49 <epoleacov> But what about local storage for ModuleManager, means storage of information which modules installed, etc.?
Sep 14 18:00:00 <ralphschindler> if you give it a path to a shared resource or an in-project resource, the end is the same, no?
Sep 14 18:00:04 <Thinkscape> epoleacov: local cache per-app
Sep 14 18:00:17 <PadraicB> rdohms, it would be optional. For Modules, the default would be per-app I assume.
Sep 14 18:00:19 <rdohms> i dont like the ideia of modmanager ending up as pear ... it should be objective and concise
Sep 14 18:00:43 <EvanDotPro> epoleacov: you would override the config for the "shared" module and point it to a local storage point.
Sep 14 18:01:08 <Thinkscape> rdohms: Module Manager is not pear. It's job is to initialize() and report to the app what modules are available and what they do (among other things)
Sep 14 18:01:17 <weierophinney> rdohms, not sure what you're getting at...
Sep 14 18:01:21 <Thinkscape> rdohms: Mod Manager will not replace nor try to imitate distribution system.
Sep 14 18:01:40 <PadraicB> rdohms, the mod manager would install stuff from a source - it's not PEAR but it does address similar goals for Modules. PEAR is just a glorified download and copier
Sep 14 18:01:45 <rdohms> Thinkscape: yes but once it starts doing shared-dir and tracking states, and etc.. it will start doing too much
Sep 14 18:02:01 <prolic> rdohms +1
Sep 14 18:02:08 <Thinkscape> what do you mean "too much" ?
Sep 14 18:02:20 <weierophinney> rdohms, shareddir is really only about whether or not the module manager cares where the module is installed
Sep 14 18:02:28 <PadraicB> rdohms, it will nothing that you couldn't do manually.
Sep 14 18:02:31 <weierophinney> i.e., does it have to be in the same project tree?
Sep 14 18:02:33 <EvanDotPro> shared dir is nothing more than a path.
Sep 14 18:02:46 <weierophinney> I see it as a non-issue, tbh
Sep 14 18:02:48 <tgodar> we got rsync... think move on
Sep 14 18:03:16 <Thinkscape> keep in mind: module directories will be immutable. local app-modules and shared-dir modules are untouched by mod manager. All stateful information is held in application directory (or local cache)
Sep 14 18:03:35 <PadraicB> Right then, I could maybe 2 -1s - rdohms, want to bring it up on the ML for further discussion? Don't want to run you over in this quick meeting
Sep 14 18:03:36 <EvanDotPro> Thinkscape: +1
Sep 14 18:03:36 <tgodar> err symbolic links... path local shared seems non issue
Sep 14 18:03:40 <rdohms> ok, but will it manage installed modules? cause then it needs to remember where the shared-dir is, instead of looking in the defualt in-project folder for example
Sep 14 18:03:55 <Thinkscape> rdohms: you will have to manually configure it
Sep 14 18:04:04 <EvanDotPro> rdohms: look over the ModuleCollection and ModuleLoader classes here: https://github.com/EvanDotPro/zf2/tree/prototype/mvc-module/modules/Zf2Module/src/Zf2Module
Sep 14 18:04:10 <Thinkscape> (application config)
Sep 14 18:04:18 <PadraicB> Fourth point: Perform on-demand loading of modules (via call or combined with spl autoloader)?
Sep 14 18:04:42 <rdohms> i'll look inot it and bring it up in the ML if need be
Sep 14 18:04:43 <PadraicB> EvanDotPro, you're the resident expert here apparently?
Sep 14 18:04:48 <ralphschindler> -1 on all things Module Manager related to the act of "installing"
Sep 14 18:04:51 <weierophinney> PadraicB, what does that mean, exactly? As in Runtime? I believe we already have that...
Sep 14 18:05:05 <rdohms> on-demand loagins is just autolaod, or bootstrap?
Sep 14 18:05:22 <weierophinney> ralphschindler, can you elaborate? I think by "install", we're talking getting configuration out, public assets out...
Sep 14 18:05:23 <PadraicB> ralphschindler, so what installs Modules? My aching fingers at 11pm?
Sep 14 18:05:36 <weierophinney> PadraicB, LOL
Sep 14 18:05:49 <ralphschindler> by install i mean the act of putting code in the proper place initially- not asset managment
Sep 14 18:05:59 <prolic> we should have 2 seperate objects: ModuleManager (caring about Runtime) and a ModuleInstaller (caring of Installation and Uninstallation), that also follows the single responsibility prinicple
Sep 14 18:06:22 <tgodar> as someone who does not use tool I like that
Sep 14 18:06:33 <Thinkscape> ralphschindler: Manager will not move modules' files
Sep 14 18:06:42 <PadraicB> prolic +1, EvanDotPro has a Module Manager in prototype that is looking good.
Sep 14 18:06:43 <Thinkscape> ralphschindler: it will just scan them and report back what is available...
Sep 14 18:07:11 »» EvanDotPro takes note to change ModuleCollection to ModuleManager
Sep 14 18:07:57 <PadraicB> ralphschindler, want to raise your objections on the ML? For those voting -1, we'll bring the topics back next meeting.
Sep 14 18:07:59 <EvanDotPro> currently, it doesn't even do any scanning. It only cares about what modules have been "asked for"
Sep 14 18:08:13 <ralphschindler> yeah - i think there are too many unknowns at the moment
Sep 14 18:08:28 <ralphschindler> a lot of this stuff talks about Zend_Tool and a "zf environment" but we don't know what those look like exactly
Sep 14 18:08:29 <PadraicB> ralphschindler, agreed.
Sep 14 18:08:37 <Rvl> Am I missing the idea about what you mean with modules, I think of (articles module, event/calendar module, online store module, ...). As it is like I interpret it, wouldn't it be sufficient to just copy the module dir to your application and run some sort of install script and that is it instead of using all the overhead you are proposing
Sep 14 18:08:39 <weierophinney> ralphschindler, the discussion so far has not included having the MM do any installation tasks, only discovery.
Sep 14 18:08:43 <ralphschindler> is a project ZF enabled? is the users home directory ZF enabled?
Sep 14 18:08:44 <ralphschindler> etc
Sep 14 18:08:45 <PadraicB> Point 5: Handle discovering, registering, loading and merging of: LOTS OF STUFF Anyone disagree?
Sep 14 18:08:47 <Rvl> or am I completely missing the point
Sep 14 18:08:59 <tgodar> "A Module is a collection of code and other files that solves a more specific atomic problem of the larger business problem. The sum of all modules within an application attempt the solve the larger business problem."
Sep 14 18:09:00 <weierophinney> Rvl, you haven't been following the ML, clearly.
Sep 14 18:09:00 <EvanDotPro> Rvl: what overhead is being proposed?
Sep 14 18:09:11 <weierophinney> PadraicB, I'm +1
Sep 14 18:09:12 <PadraicB> Rvl, the overhead is simple automation of all those manual steps.
Sep 14 18:09:52 <Rvl> running some sort of install.php seems pretty straightforward to me
Sep 14 18:10:06 <epoleacov> yeah, but some modules require actions after installtion and before ready to work.
Sep 14 18:10:46 <PadraicB> Rvl, it really depends on Module complexity. We can't assume the obvious - Modules may depends on 3 other Modules in time and need their own special setup tasks.
Sep 14 18:10:57 <PadraicB> Anyone commenting on Point 5?
Sep 14 18:11:01 <hhatfield> question about the items marked "if MVC module…". Is that specifically talking about the ZF2 MVC?
Sep 14 18:11:04 <weierophinney> Rvl, examples include merging configuration, etc. It's also useful to be able to do that runtime, instead of executing a script on the CLI.
Sep 14 18:11:14 <alextech> how does it discover? what does it look for? I am thinking something like a config file (xml/json/ini) that contains a listing of all files and configurations (eg. db schemas) that will be copied and executing. something like RPM or DEB package.
Sep 14 18:11:21 <weierophinney> epoleacov, for those, we'll likely have some functionality.
Sep 14 18:11:32 <PadraicB> hhatfield, yes - presumable referring to Modules using MVC stuff like controllers/views
Sep 14 18:11:32 <Thinkscape> ralphschindler: weierophinney: I believe that the scanning/installation should be smart enough, to run once, JIT. So for example: I copy over my SEO module to /app/modules/SEO. On next http request, the application sees new SEO directory and scans it for module assets, then caches it. Alternatively you can "warm" the cache via CLI.
Sep 14 18:11:38 <EvanDotPro> PadraicB: i think point 5) is almost entirely handled by the current init()
Sep 14 18:11:40 <weierophinney> hhatfield, yes
Sep 14 18:11:49 <prolic> point 5: discovering, registering and merging: is it meant as runetime task or installation task?
Sep 14 18:11:54 <weierophinney> Thinkscape, agreed
Sep 14 18:12:02 <weierophinney> prolic, either and/or both.
Sep 14 18:12:16 <ralphschindler> Thinkscape: now we have a module infrastructure that REQUIRES devtime tooling
Sep 14 18:12:22 <weierophinney> prolic, the idea is this is done as a class – so you can invoke that class from a web app, or from a CLI script.
Sep 14 18:12:29 <PadraicB> prolic, both - though for production a once-off task would create caches (better performance)
Sep 14 18:12:52 <prolic> the cache could also be done during installation
Sep 14 18:13:11 <PadraicB> ralphschindler, no - the tooling can be ignored but then you'd lose efficiency.
Sep 14 18:13:12 <ralphschindler> so is there a module frontend to manage modules that is a module?
Sep 14 18:13:25 <epoleacov> i think be better to use interfaces inplementation in bootstraps like Module\Installable, Module\Updateable etc. In this case MM will know which module require installation.
Sep 14 18:13:29 <ralphschindler> or, does the default ZF application have this already baked in?
Sep 14 18:13:36 <PadraicB> ralphschindler, can't wait for someone to write that...
Sep 14 18:13:43 <Thinkscape> ralphschindler: ZF is used extensively on shared envs. Drupal does it just like I've described. First request is very slow becase it builds the cache by traversing i.e. 50+ modules, but afterwards it's very fast because everything is "mapped".
Sep 14 18:13:44 <ralphschindler> you see my point though-
Sep 14 18:13:51 <tgodar> implies install/modify/uninstall
Sep 14 18:13:59 <ralphschindler> Drupal is not a blank application stack, its a cms platform
Sep 14 18:14:12 <ralphschindler> so, in my mind, its not a good comparison
Sep 14 18:14:15 <Rvl> weierophinney: probably you are right but I think a specific installation per module would be sufficient. (Why would for example merging config files be needed as you only need to load the specific module config). But I will not pollute the conversation anymore as I'm not up to date with current status
Sep 14 18:14:28 <Thinkscape> ralphschindler: that proves my point - it's more complex at this moment, yet it manages it very nicely.
Sep 14 18:14:39 <PadraicB> ralphschindler, I don't build blank application stacks however... The caching/compiling does help.
Sep 14 18:14:52 <ralphschindler> but i wouldn't want to write an application on drupal- as its already too opinionated on how things are done
Sep 14 18:14:56 <PadraicB> Anyway, any firm -1 to point 5? Otherwise:
Sep 14 18:15:01 <PadraicB> Point 6: Manage static assets (module's directory is immutable, its assets are copied/linked to application's main public/)
Sep 14 18:15:26 <PadraicB> ralphschindler, you think ZF is unopinionated???
Sep 14 18:15:41 <ralphschindler> -1 i don't think we know enough about what a) a module truly looks like and b) how much interaction it has with the baked in ZF application layer
Sep 14 18:15:59 <ralphschindler> PadraicB: more or less, i've seen user auth systems written 100 different ways
Sep 14 18:16:02 <prolic> about immutable assets: I use the dojo build system for css very often, so -1 to immutable css
Sep 14 18:16:10 <weierophinney> ralphschindler, we can leave that flexible by using an EventManager (which is how EvanDotPro has already coded it)
Sep 14 18:16:31 <Thinkscape> S2 does something similar - it populates /app/cache/ directory with maps for everything, from di containers to compiled routes, uri generators, assetic file maps etc.
Sep 14 18:16:32 <EvanDotPro> weierophinney: +1, i left it open-ended like this for this exact reason.
Sep 14 18:16:40 <weierophinney> prolic, what is meant here is having the assets in the module immutable; they are then moved into a public area, where they can be mutable
Sep 14 18:16:45 <PadraicB> Assuming NOBODY is -1 on managing static assets. Yes, you can still do it manually if you really want to
Sep 14 18:16:47 <Thinkscape> S2 doesn't require cli for that either.
Sep 14 18:17:00 <Rvl> agreeds with ralphschindler -1
Sep 14 18:17:14 <weierophinney> PadraicB, the bigger question on point 6 is: do we code it, or delegate it to 3rd party tools?
Sep 14 18:17:22 <ralphschindler> i think asset management needs some good planning on its own
Sep 14 18:17:28 <weierophinney> Regardless, we can likely provide hooks or events for it.
Sep 14 18:17:33 <Akrabat> I may be -1 on 6.
Sep 14 18:17:49 <Akrabat> I think it needs more understanding of how it would work in practice
Sep 14 18:18:00 <EvanDotPro> ralphschindler, Rvl: please raise your -1's to point 5 on the ML so I can go over them and see how they clash with the current direction.
Sep 14 18:18:09 <weierophinney> Akrabat, agreed, but I'd still claim it's something the MM should likely assist with.
Sep 14 18:18:11 <prolic> +1 on 6 when on ModuleInstaller, not on ModuleManager
Sep 14 18:18:30 <ralphschindler> ok EvanDotPro
Sep 14 18:18:35 <intiilapa> what means S2?
Sep 14 18:18:36 <PadraicB> prolic, it would be an install task (or manual do-by-hand task)
Sep 14 18:18:45 <PadraicB> S2 is Symfony 2
Sep 14 18:18:47 <Akrabat> weierophinney: that's possible. I also like the idea of leaving it to a cli installer or manual installation readme
Sep 14 18:18:53 <prolic> PadraicB, ok
Sep 14 18:19:07 <Akrabat> but as I say, atm, I have don't have a clear view on how it would work
Sep 14 18:19:12 <PadraicB> So tentative maybe needing more ML examples/prototyping?
Sep 14 18:19:19 <weierophinney> PadraicB, yes
Sep 14 18:19:23 <PadraicB> cool
Sep 14 18:19:24 <ralphschindler> yes, we need more prototyping here
Sep 14 18:19:31 <Akrabat> yep
Sep 14 18:19:37 <PadraicB> Point 7: Handle modules registry
Sep 14 18:19:42 <rdohms> Akrabat: take a look at assetic and Sf2 it will shine some light
Sep 14 18:19:47 <ralphschindler> the more infrastucure we build, the more of a performance impact it will have
Sep 14 18:19:51 <PadraicB> I'm looking at this sideways. Thinkscape?
Sep 14 18:20:00 <ralphschindler> se we need to balance what happens during runtime vs. the dev time tools
Sep 14 18:20:00 <weierophinney> I have no clue what point 7 is about; first we've really talked about a module registry...
Sep 14 18:20:12 <ralphschindler> there are still people on windows without a real CLI prompt
Sep 14 18:20:17 <Thinkscape> ralphschindler: that is a challenge we'll tackle. I strongly believe in cache-early and going KISS.
Sep 14 18:20:39 <weierophinney> back on-topic: what is point 7 about?
Sep 14 18:20:45 <Thinkscape> also - ZF2 modules will not require cli to function
Sep 14 18:20:48 <PadraicB> ralphschindler, don't be silly. They have MSDOS. It's really good. (I disclose MS paid me to say that )
Sep 14 18:20:55 <Akrabat> I don't understand point 7 either
Sep 14 18:21:03 <PadraicB> Okay, skipping for now.
Sep 14 18:21:05 <Akrabat> ralphschindler: windows people have php.exe too
Sep 14 18:21:09 <ralphschindler> -1 on #7
Sep 14 18:21:15 <ralphschindler> haha, yeah Akrabat
Sep 14 18:21:16 <tgodar> 7 is module specific registry?
Sep 14 18:21:17 <Thinkscape> 7. mod manager will handle module's metadata cache.
Sep 14 18:21:18 <alextech> registry with vars only within the scope of module maybe?
Sep 14 18:21:32 <Thinkscape> this is for 8. and 9.
Sep 14 18:21:38 <PadraicB> Ahh, you mean a record of what Module's are installed?
Sep 14 18:21:42 <EvanDotPro> Thinkscape: so provide a proxy to the modules Module classes?
Sep 14 18:22:01 <Thinkscape> EvanDotPro: not really
Sep 14 18:22:03 <Thinkscape> Zend\Module\Manager::isLoaded('SEO');
Sep 14 18:22:12 <Thinkscape> Zend\Module\Manager::isAvailable('SEO')
Sep 14 18:22:15 <Thinkscape> Zend\Module\Manager::isInstalled('SEO')
Sep 14 18:22:22 <weierophinney> Thinkscape, why is this necessary?
Sep 14 18:22:24 <Thinkscape> Zend\Module\Manager::init('SEO')
Sep 14 18:22:30 <PadraicB> EvanDotPro, that would work but not if installed to a shared directory probably. Hard question...
Sep 14 18:22:35 <Thinkscape> for debuggin, testing and explicit loading
Sep 14 18:22:38 <weierophinney> I'd not expect to test for that stuff in application code – only the classes...
Sep 14 18:22:46 <ralphschindler> -1 on 8
Sep 14 18:22:57 <ralphschindler> you'll get an exception if you run into a situation where things are missing
Sep 14 18:22:59 <EvanDotPro> PadraicB: it would work in a shared directory just fine with how the module loader works now.
Sep 14 18:23:02 <weierophinney> Thinkscape, can you explain a bit more?
Sep 14 18:23:14 <Thinkscape> For testing if a module exists - for example User module can use GeoIP module - but if that module does not exist, some functionality will be disabled.
Sep 14 18:23:15 <weierophinney> Where would this code be called?
Sep 14 18:23:18 <ralphschindler> there's no need that every request should check for the existence of a module
Sep 14 18:23:21 <EvanDotPro> (not saying i'm +1, just clarifying the current functionality)
Sep 14 18:23:24 <Akrabat> 8 feels like a installation issue
Sep 14 18:23:27 <ralphschindler> +1 on weierophinney's question
Sep 14 18:23:57 <weierophinney> Thinkscape, check on whether a class exists, not whether or not the module is there... if (!get_class('GeoIp\Some\Functionality'))

Unknown macro: { // bail }

Sep 14 18:24:08 <PadraicB> EvanDotPro, hmm - cool if true! (Must read more of your code!)
Sep 14 18:24:14 <Thinkscape> weierophinney: module is not only a collection of classes
Sep 14 18:24:24 <Thinkscape> you might need to init() geoip before it works.
Sep 14 18:24:38 »» EvanDotPro gets the feeling a lot of people haven't read through my current module prototype :-p
Sep 14 18:24:52 <PadraicB> EvanDotPro
Sep 14 18:25:15 <EvanDotPro> i can almost guarantee this part of the meeting would have gone much smoother otherwise
Sep 14 18:25:19 <epoleacov> i think not good idea to check class existing, possible better to use messagin system, and if mesaage to registered disable functionality.
Sep 14 18:25:24 <weierophinney> Thinkscape, Right now, the MM operates outside the application scope. What you're suggesting would imply we'd need to inject it all the way down, or make it a singleton. Latter is a bad idea; former feels dirty
Sep 14 18:25:29 <prolic> EvanDotPro - for our excuse, it was a short time between your release and this meeting, I had only time for a shorter look
Sep 14 18:25:44 <PadraicB> Point 8: Handle simple module dependencies (those which have not been not handled by Pear/Pyrus, i.e. via manual installation)
Sep 14 18:25:59 <ralphschindler> EvanDotPro: looking at user-module and guestbook modules
Sep 14 18:26:03 <EvanDotPro> prolic: very true, that's valid
Sep 14 18:26:05 <PadraicB> Though it's already mentioned - any -1s and reasons?
Sep 14 18:26:16 <prolic> point 8: what is a simple and what is a complex dependency?
Sep 14 18:26:23 <weierophinney> prolic, untrue. It's been working since late last week.
Sep 14 18:26:25 <PadraicB> brb - someone post pt 9 in a few
Sep 14 18:26:38 <Thinkscape> weierophinney: yes, that was my prime idea. Modules are packaged. Packaging/metadata has to be read/handled by something. This means you need module manager one way or another. IMO you don't need to use Zend\Application to work with modules.
Sep 14 18:26:56 <EvanDotPro> weierophinney: well it's relative to what "short time" is, since it was only 1 weekend.
Sep 14 18:27:07 <weierophinney> EvanDotPro, I was being facetious.
Sep 14 18:27:39 <Thinkscape> prolic: complex is what RPM does and handles. Simple is just knowing, that module X requires module Y to function and will refuse to init() otherwise.
Sep 14 18:27:54 <weierophinney> Thinkscape, again, though, currently that metadata becomes part of application configuration (i.e., injected via DI).
Sep 14 18:28:01 <intiilapa> module manager are a component in the library?
Sep 14 18:28:08 <Thinkscape> intiilapa: yes
Sep 14 18:28:09 <weierophinney> So, I'm not sure we need the capabilities – simply have dependencies.
Sep 14 18:28:16 <prolic> so module x depending on module y, i will install module x and fail because module y is missing? is this too complex?
Sep 14 18:28:20 <ralphschindler> question: do modules have to have a package structure to work in the zf system? what is the minimal requirement? does it have to have metadata?
Sep 14 18:28:38 <weierophinney> prolic, a package manager would take care of installing dependencies.
Sep 14 18:28:46 <Akrabat> I don't really understand 8 I think. Doesn't the installer worry about dependent modules?
Sep 14 18:28:47 <intiilapa> ralphschindler: Information.php file and/or composer.json
Sep 14 18:28:57 <weierophinney> ralphschindler, minimal requirement is a Module class under the module namespace.
Sep 14 18:28:59 <hhatfield> +1 Akrabat
Sep 14 18:29:05 <ralphschindler> i thought it was Module.php ?
Sep 14 18:29:08 <Akrabat> and if you don't use the installer, then you have to read the README file
Sep 14 18:29:09 <weierophinney> intiilapa, s/Information/Module/
Sep 14 18:29:10 <EvanDotPro> ralphschindler: currently the only requirement is that it has a Module class in Module.php, and sets up it's owne autoloader
Sep 14 18:29:12 <weierophinney> ralphschindler, it is.
Sep 14 18:29:29 <weierophinney> intiilapa, composer.json is unnecessary, and going to be removed.
Sep 14 18:29:32 <Akrabat> EvanDotPro: actually, it doesn't have to set up an autoloader
Sep 14 18:29:33 <Thinkscape> prolic: dependency tree will be propagated/cloned in packaging system. If you use Pear to install your module X then it will auto-install Y. If you manually unpack X to modules/ directory, then you have to manually install Y or it will fail to init()
Sep 14 18:29:36 <EvanDotPro> and the autoloader is something we're looking at caching to prevent a plethora of autoloaders being registered every time.
Sep 14 18:30:10 <EvanDotPro> true, it doesn't have to provide an autoloader; only if it needs to load some php classes.. automatically
Sep 14 18:30:26 <prolic> i could expect the moduleInstaller to ask me, if he should download module y via pyrus or whatever our default will be
Sep 14 18:30:26 <epoleacov> but it related module has updated after installation, and functionallity was disappear?
Sep 14 18:30:31 <Akrabat> EvanDotPro: exactly
Sep 14 18:31:23 <prolic> I think ALL classes should be autoloadable from everywhere in your application, not neccessary to bootstrap a module first
Sep 14 18:31:24 <Thinkscape> as per 8. metadata and dependencies are required to handle things like asset resolving, loading dependent modules (i.e. initing() db module also inits() all adapters), configuration merging, routes merging, module queries.
Sep 14 18:31:36 <ralphschindler> so the most minimal requirement, and the only runtime implication is that for each module, Module->init() is called, right?
Sep 14 18:31:50 <EvanDotPro> so currently, the only thing that makes a module a module is the presence of Module.php (containing ModuleName\Module class which can be empty).. That simply serves to tell the ModuleLoader that yes, this directory is in fact a module.
Sep 14 18:31:52 <Thinkscape> prolic: consider you have 100 modules in shared dir. You current application just needs 5 of them + 5 other, locally installed.
Sep 14 18:32:03 <EvanDotPro> ralphschindler: even init() is optional.
Sep 14 18:32:45 <PadraicB> Back to basics, what if anything was decided about point 8?
Sep 14 18:32:45 <Thinkscape> ralphschindler: the existence of init() is optional
Sep 14 18:33:06 <Thinkscape> if you install a db-adapter-firebird module, then it just provides autoloadable classes for \Zend\Db\Adapter *
Sep 14 18:33:12 <Thinkscape> No need to init that.
Sep 14 18:33:19 <PadraicB> ping ping ping
Sep 14 18:33:26 <EvanDotPro> <?php namespace MyModule; class Module { } ?> is the minimum as it stands.
Sep 14 18:33:42 <intiilapa> we have an interface for the module class?
Sep 14 18:33:42 <prolic> when i'm in module x and want to load a class from module y, then i need to init module y first ?
Sep 14 18:33:44 <weierophinney> PadraicB, nothing so far – still in discussion.
Sep 14 18:34:02 <Akrabat> prolic: no
Sep 14 18:34:03 <weierophinney> intiilapa, no. Duck typing for now to discover if we need anything more.
Sep 14 18:34:05 <Thinkscape> prolic: no, it will happen automagically
Sep 14 18:34:15 <PadraicB> Back to the ML then? We're short on time by -4 minutes
Sep 14 18:34:28 <Thinkscape> ok
Sep 14 18:34:29 <Thinkscape> last one
Sep 14 18:34:30 <Thinkscape> quick
Sep 14 18:34:34 <Thinkscape> https://gist.github.com/1217290
Sep 14 18:34:35 <weierophinney> prolic, autoloaders are setup before the application is executed – meaning that when you need the class from module y, you can discover it.
Sep 14 18:34:41 <Thinkscape> we're discussing how module directory structure should look like
Sep 14 18:34:44 <prolic> ok
Sep 14 18:34:56 <weierophinney> Thinkscape, -1 on that structure.
Sep 14 18:35:00 <Thinkscape> Above are 2 examples of how it might look like
Sep 14 18:35:00 <EvanDotPro> prolic: be sure to check out the module prototype when you have time.
Sep 14 18:35:04 <Thinkscape> your comments?
Sep 14 18:35:06 <weierophinney> Should follow PSR-0 internally
Sep 14 18:35:14 <intiilapa> Thinkscape: app is different of a module?
Sep 14 18:35:20 <Thinkscape> weierophinney: what for ?
Sep 14 18:35:27 <weierophinney> so either have Statistics/Controller/..., or Statistics/src/Statistics/Controller/
Sep 14 18:35:27 <ralphschindler> -1 on any required structure
Sep 14 18:35:31 <Akrabat> I believe that there should be no requirements on structure
Sep 14 18:35:39 »» EvanDotPro doesn't see any reason to force a structure.
Sep 14 18:35:41 <Akrabat> it's entirely up to the module developer
Sep 14 18:35:43 <weierophinney> but, really Akrabat+1
Sep 14 18:35:49 <prolic> EvanDotPro: I will, and send you further feedback of course
Sep 14 18:35:50 <tgodar> agreed
Sep 14 18:35:56 <EvanDotPro> prolic: thank you much
Sep 14 18:36:18 <Akrabat> I think we could possibly provide a set of "conventions"
Sep 14 18:36:23 <Thinkscape> There are reasons for consistent structure...
Sep 14 18:36:29 <ezimuel> Akrabat +1
Sep 14 18:36:31 <EvanDotPro> any "structure" we discuss should be purely for "convention" and/or "zf create module Foo"
Sep 14 18:36:31 <Thinkscape> it helps with resolving, scanning and such
Sep 14 18:36:37 <weierophinney> Thinkscape, the zf1-style structure has caused a ton of confusion, as well as issues with autoloading. That's my main reason.
Sep 14 18:36:41 <Akrabat> especially around assets/tests/docs
Sep 14 18:36:44 <EvanDotPro> Thinkscape: the only thing that needs to be resolved is Module.php, no?
Sep 14 18:36:53 <intiilapa> I think we need an helper to merge all js and css in one file for the prod env, still the image assets
Sep 14 18:36:54 <weierophinney> But, as ralphschindler, EvanDotPro, and Akrabat say, there's really no reason to enforce a structure.
Sep 14 18:36:55 <Akrabat> Thinkscape: there shouldn't be any scanning/resolving. Module.php does all that
Sep 14 18:37:07 »» Thinkscape changes topic: "What should a CONVENTION for a module dir structure look like?"
Sep 14 18:37:09 <ralphschindler> Thinkscape: assumptions shouldn't be made, the module should have explicit maps by default, and be provided alternatives file maps as configuration
Sep 14 18:37:18 <EvanDotPro> Thinkscape: much better
Sep 14 18:37:19 <EvanDotPro>
Sep 14 18:37:23 <weierophinney> intiilapa, that was talked about earlier. Move on.
Sep 14 18:37:35 <Thinkscape> ralphschindler: this brings verboseness where it is not required
Sep 14 18:37:37 <Akrabat> Thinkscape:
Sep 14 18:37:40 <intiilapa> Thinkscape: what is the goal of your app dir? the app should be a module
Sep 14 18:37:50 <weierophinney> Thinkscape, I'm creating an alternate gist...
Sep 14 18:37:52 <Thinkscape> for example - I have 1 class Adapter\Firebird.php ---- do I need map for that ?
Sep 14 18:38:06 <Thinkscape> or can I just put it into modules/firebird/src/Adapter/Firebird.php ?
Sep 14 18:38:11 <Thinkscape> and this module will work?
Sep 14 18:38:22 <ralphschindler> Thinkscape: that sounds like a library component
Sep 14 18:38:25 <Akrabat> Thinkscape: yes. How else will the DI find it to attach it to the DB?
Sep 14 18:38:37 <ralphschindler> but really, if it must be a module, the it can be found b/c the Module.php has setup a path in the autoloader
Sep 14 18:38:48 <EvanDotPro> ralphschindler: +1
Sep 14 18:38:52 <Thinkscape> ralphschindler: you don't need Module.php for that
Sep 14 18:38:56 <tgodar> ties back to the share/local item I think... Not depending on file structure makes most sense to me - hook on what I am hearing is the one requirement the Module.php
Sep 14 18:38:58 <Akrabat> ralphschindler wrote it more nicely for me
Sep 14 18:39:14 <weierophinney> Thinkscape, http://pastebin.com/PRuCzQsq
Sep 14 18:39:14 <ralphschindler> for ZF modules, i'd say they always need a clear entry point, such as Module.php
Sep 14 18:39:20 <ralphschindler> otherwise its just code in a directory
Sep 14 18:39:24 <Thinkscape> you don't need any function calls... because I can assume: \ModuleNamespace\Class.php => /modules/Module/src/Class.php
Sep 14 18:39:25 <ralphschindler> and no clear entry point
Sep 14 18:39:33 <EvanDotPro> weierophinney: +1
Sep 14 18:39:41 <ralphschindler> i am +1 on a suggested structure
Sep 14 18:39:46 <ralphschindler> but we should not enforce a structure
Sep 14 18:39:56 <weierophinney> ralphschindler, this is for a suggested structure.
Sep 14 18:40:00 <weierophinney> not an enforced one
Sep 14 18:40:01 <ralphschindler> some people might want to retrofit code into a module, etc
Sep 14 18:40:04 <EvanDotPro> ralphschindler: the topic has been changed to suggested structure
Sep 14 18:40:06 <weierophinney> I forgot to put Module.php in there.
Sep 14 18:40:06 <prolic> +1 for default structure + abbility to override
Sep 14 18:40:08 <Akrabat> Thinkscape: general assumption is that modules will prefer the classmap autoloader as it's so much faster than using the standard one
Sep 14 18:40:20 <tgodar> prolic +1
Sep 14 18:40:21 <Thinkscape> weierophinney: that's exactly what I've had in proposal 2
Sep 14 18:40:30 »» Thinkscape points to https://gist.github.com/1217290 - scroll down
Sep 14 18:40:34 <weierophinney> revised: http://pastebin.com/qE2JbFLY
Sep 14 18:40:57 <weierophinney> Thinkscape, I hadn't seen the second proposal...
Sep 14 18:41:04 <PadraicB> So we're sort of agreeing in principle to directory structure being a convention? Yes?
Sep 14 18:41:06 <Rvl> Module/src/Module, why not Module/src/
Sep 14 18:41:11 <Thinkscape> its there since begining
Sep 14 18:41:16 <ralphschindler> sorry guys, but to be clear, Thinkscape is arguing that specific placement of assets implies an automatic wiring/mapping, that is why I am impressing that a Module.php be the only requirement
Sep 14 18:41:30 <weierophinney> Rvl, so that you can add src\Module as a directory to the StandardAutoloader
Sep 14 18:41:32 <ralphschindler> thus making this structure (suggested)
Sep 14 18:41:34 <Akrabat> I'm stronly against any automatic wiring
Sep 14 18:41:35 <weierophinney> PSR-0 compliant
Sep 14 18:41:46 <weierophinney> ralphschindler, +1
Sep 14 18:41:50 <Thinkscape> Akrabat: how about calling it "default" wiring ?
Sep 14 18:41:57 <Akrabat> on that revised one, why is Module.php outside of Statistics?
Sep 14 18:41:58 <weierophinney> PadraicB, yes
Sep 14 18:42:01 <EvanDotPro> Rvl: also to allow a module to contain >1 root namespace in a clean way, no?
Sep 14 18:42:06 <Akrabat> Thinkscape: I'm still against it as it implies StandardAutoloader
Sep 14 18:42:11 <weierophinney> Akrabat, CRAP! I messed up!
Sep 14 18:42:18 <Akrabat> phew
Sep 14 18:42:18 <intiilapa> weierophinney: Module.php is not inside the module?
Sep 14 18:42:30 <weierophinney> Akrabat, here: http://pastebin.com/xUGuQCRS
Sep 14 18:42:42 <weierophinney> intiilapa, it was supposed to be. I messed up. See previous.
Sep 14 18:42:44 <Akrabat> that's better
Sep 14 18:42:47 <intiilapa> ok
Sep 14 18:43:03 <Akrabat> question: we're moving away from the .classmap convention to autoload_classmap?
Sep 14 18:43:08 <Thinkscape> why is configs in Statistics ?
Sep 14 18:43:09 <Akrabat> cos I'm definitely +1 to that
Sep 14 18:43:12 <epoleacov> weierophinney: public under application dir?
Sep 14 18:43:16 <Thinkscape> PSR-0 doesnt work with *.ini
Sep 14 18:43:17 <intiilapa> autoload_* is related to a default behavior or the responsability of Module class?
Sep 14 18:43:24 <ralphschindler> Akrabat: i think we need to, some ide's and editors don't show the . files
Sep 14 18:43:28 <Thinkscape> public in Statictics?
Sep 14 18:43:29 <weierophinney> Akrabat, some folks aren't liking the hidden files.
Sep 14 18:43:30 <intiilapa> Thinkscape: Di, routes, etc.
Sep 14 18:43:31 <alextech> if there may not be an mvc with a url pointing to the module, how will browser ever get to public?
Sep 14 18:43:41 <Akrabat> ralphschindler, weierophinney: Good. I'm one of them
Sep 14 18:43:42 <weierophinney> intiilapa, it's just an example.
Sep 14 18:43:53 <Thinkscape> alextech: files will be merged/copied to app's public
Sep 14 18:43:54 <Akrabat> alextech: that's the assets discussion we had earlier
Sep 14 18:43:56 <ralphschindler> code paths shouldn't be hidden for debugging reasons alone (and others)
Sep 14 18:43:57 <EvanDotPro> for the sake of redundancy, this is a screenshot from a related conversation i had with Thinkscape over the weekend: http://evan.pro/caps/84668d.png
Sep 14 18:44:04 <weierophinney> Thinkscape, those are module congifurations
Sep 14 18:44:05 <EvanDotPro> (re: directory structure)
Sep 14 18:44:06 <Thinkscape> alextech: (asset management)
Sep 14 18:44:18 <PadraicB> Alright, it's 19:41 here so can we assume meeting over?
Sep 14 18:44:26 <PadraicB> Hmm, my watch is slow...
Sep 14 18:44:32 <weierophinney> EvanDotPro, that's basically exactly what I propose.
Sep 14 18:44:38 <Akrabat> EvanDotPro: I prefer views under src tbh
Sep 14 18:44:44 <Thinkscape> weierophinney: that doesn't make sense...
Sep 14 18:44:50 <Akrabat> but I won't really mind
Sep 14 18:44:56 »» Thinkscape calls it today - meeting is over ! THANK YOU!!
Sep 14 18:44:57 <weierophinney> Thinkscape, I don't know if we're looking at the same thing
Sep 14 18:45:01 <Thinkscape> Stay only if you want to
Sep 14 18:45:14 <EvanDotPro> Akrabat: the cool thing is, in your modules you can do that, since modules will add their own view paths
Sep 14 18:45:20 <Akrabat> yep
Sep 14 18:45:23 <Thinkscape> ok, got the revised one http://pastebin.com/xUGuQCRS
Sep 14 18:45:33 <ralphschindler> +1 on EvanDotPro
Sep 14 18:45:33 <Thinkscape> (gist is better because it versions)
Sep 14 18:45:34 <weierophinney> Thinkscape, I was trying to get across this: modules/Statistics/configs/...
Sep 14 18:45:35 <Akrabat> PadraicB: yeah - meeting over. Bikeshed discussion starting
Sep 14 18:45:57 <weierophinney> Thinkscape, does that look better, then?
Sep 14 18:46:03 <ezimuel> EvanDotPro +1
Sep 14 18:46:20 <Thinkscape> weierophinney: so you're proposing: everything php goes PSR-0 style, everything else, plural-lowercased-dir ?
Sep 14 18:46:37 <alextech> I hope the asset management is able to well manage assets with duplicate functionality. I do not want joomla nonsense with 5 jQuery libraries loaded at onces because I have modules from multiple vendors
Sep 14 18:46:41 <ralphschindler> out of curiosity, how does the system know the namespace of the module?
Sep 14 18:46:43 <weierophinney> Thinkscape, yes – and PHP code under a "src" or "php" tree.
Sep 14 18:46:57 <Thinkscape> and multiple namespaces under src - if module author wants to.
Sep 14 18:46:58 <weierophinney> (or "lib" or "library"... something denoting it's source code)
Sep 14 18:46:58 <Akrabat> ralphschindler: namespace of module = module directory name
Sep 14 18:47:03 <weierophinney> Thinkscape, yes.
Sep 14 18:47:17 <ralphschindler> so, it can be modules/Vendor/ModuleName ?
Sep 14 18:47:23 <Thinkscape> open question: what about injecting Zend* namespace?
Sep 14 18:47:23 <Akrabat> ralphschindler: otherwise Statistics\Module gets difficult
Sep 14 18:47:25 <ralphschindler> or will that break things?
Sep 14 18:47:34 <intiilapa> Thinkscape: where?
Sep 14 18:47:34 <prolic> meeting over? next topic EvanDotPro: another thing that came to my mind: when i have multiple module running on one request, how can they reuse the database connection instead of using there own every time?
Sep 14 18:47:36 <Thinkscape> for example Zend\Db\Adapter\Firebird extends Zend\Db\Adapter\Abstractadapter ?
Sep 14 18:47:40 <Akrabat> ralphschindler: that should definitely work imo
Sep 14 18:47:45 <ralphschindler> Thinkscape: no
Sep 14 18:47:54 <ralphschindler> if you don't own the top level namespace, you shouldn't be using it
Sep 14 18:47:54 <EvanDotPro> prolic: that's a question i raised in my readme which is TBD
Sep 14 18:47:57 <weierophinney> prolic, I'd expect that would be something you setup at the application level
Sep 14 18:48:00 <intiilapa> prolic: Di issue I think
Sep 14 18:48:12 <tgodar> look forward to seeing more code around MM - later all
Sep 14 18:48:12 <prolic> good
Sep 14 18:48:25 <Thinkscape> so Firebird\Firebirdadapter extends Zend\Db\Adapter\Abstractadapter ?
Sep 14 18:48:35 <weierophinney> kk, let's call it a day, with the fourth item undiscussed. Ralph has some stuff to post on the ML about that anyways.
Sep 14 18:48:40 <Thinkscape> tgodar: thx. later!
Sep 14 18:48:42 <weierophinney> Thinkscape, absolutely.
Sep 14 18:49:12 <ezimuel> bye guys
Sep 14 18:49:23 <Thinkscape> ------------------------ Thanks all! Keep prototypes coming! and ML alive
Sep 14 18:49:31 <EvanDotPro> </meeting>
Sep 14 18:49:39 <ralphschindler> bye guys
Sep 14 18:49:43 <weierophinney> I'll try and get the summary posted later today; at latest, it'll be tomorrow mornign.
Sep 14 18:49:45 <epoleacov> Bye, everyone.
Sep 14 18:49:55 <prolic> ralphschindler, do you have a minute? i just wanted to ask what you think of my di extension I sent you
Sep 14 18:50:06 <PadraicB> Thanks to everyone who dropped in on the meeting
Sep 14 18:50:07 <ralphschindler> prolic: in .2
Sep 14 18:50:16 <prolic> .2?
Sep 14 18:50:19 <weierophinney> PadraicB, ++
Sep 14 18:50:23 <weierophinney> great discussions today!
</pre>
]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 14, 2011

    <p>I was not able to be at the meeting today and I have some question about the module structure.</p>

    <p>Will it be possible to have structure like this to separate the application and the public ressource?</p>

    <p>in /home/myProject we have :<br />
    /Application<br />
    – /modules/<br />
    ---- SpinDoctor/<br />
    ------ Module.php<br />
    ------ autoload_classmap.php<br />
    ------ ...<br />
    /public_html<br />
    --/index.php --> application start there.<br />
    ---- /SpinDoctor/ -->public content of the module.<br />
    ------ /img/...<br />
    ------ /css/...<br />
    ------ /js/...</p>

    <p>I will not enjoy to have everything in the public_html and have my xml, ini or other non-php file to be exposed in the public_html or make everything outside and have to manage symlink for every public directory in all module.</p>

  2. Sep 15, 2011

    <p>I like the module layout. I would simply suggest that "phpunit.xml" be changed to "phpunit.xml.dist".</p>

  3. Sep 15, 2011

    <p>Can the IRC logs be updated with the IRC names? It's now hard to read and understand who said what.</p>

    1. Sep 15, 2011

      <p>+1 <ac:emoticon ac:name="smile" /></p>