ZF2 IRC Meeting 2011-09-14

gistfile1.weechatlog

[Zend Framework 2.0 IRC Meeting channel. Next meeting: 2011-09-14 17:00 UTC; agenda: http://bit.ly/rimSDJ. Previous meeting minutes: http://bit.ly/oQ60Xm]
[18:55]  * Thinkscape : meeting starts in 5 minutes
[18:56] == rdohms [~rdohms@201.23.78.250.dedicated.neoviatelecom.com.br]
[18:56] ==  realname : Rafael Dohms
[18:56] ==  channels : #zf2-meeting #zftalk.dev
[18:56] ==  server   : adams.freenode.net [Budapest, HU, EU]
[18:56] ==  account  : rdohms
[18:56] == End of WHOIS
[18:56] <Akrabat> I have dinner in 5 minutes :)
[18:58] <weierophinney> starting in 2 or 3 minutes...
[19:00] <rdohms> kick it!
[19:00]  * Thinkscape kicks it
[19:00] <guilhermeblanco> \o/
[19:01]  * rizza headbangs.
[19:01] <Thinkscape> Hello everyone!
[19:01]  * rdohms waits for it to kick back
[19:01] <PadraicB> rizza, ouch ;)
[19:01] <weierophinney> So, Thinkscape is MODERATOR
[19:01] <ezimuel> hey guys
[19:01] <weierophinney> That means HE HAS AUTHORITY TO END DISCUSSIONS
[19:01] <weierophinney> :)
[19:01] <rdohms> weierophinney: +1
[19:02] <Thinkscape> We have estimated 1h to discuss 4 topics today
[19:02] <rizza> Thinkscape: With such great power comes… great power. That's all. Good luck!
[19:02] <Thinkscape> remember: Nothing is definite, it's only a discussion to bring us closer to the goal.
[19:02] <weierophinney> .. and we can spill over up to 30 minutes. But let's try not to. :)
[19:02] <EvanDotPro> _estimated_ being the key word
[19:02] <Thinkscape> Here's the agenda:
[19:02] <Thinkscape> 1. A brainstorm on: Best configuration style for ZF2 components
[19:03] <Thinkscape> 2. A quick talk and decision on what to do with "extra components"
[19:03] <Thinkscape> 3. A more convoluted discussion on Module Manager and goals of modules as such.
[19:03] <Thinkscape> 4. Related to 3. - Directory structure for packaging and arranging modules' files
[19:03] <Thinkscape> Let's start with 1.
[19:04] <Thinkscape> Here is the comparison http://framework.zend.com/wiki/display/ZFDEV2/Comparison+of+config+styles
[19:04] <Thinkscape> First question: have we missed anything?
[19:04] <Thinkscape> do you know any good config styles not mentioned there?
[19:04] <Thinkscape> What can we look at? What are some good patterns for that ?
[19:04] <Thinkscape> Or what would you change in these 4 styles we've outlined.
[19:04] <Thinkscape> GO! :-)
[19:04] <weierophinney> PadraicB, I believe you're opinionated on this topic?
[19:05] <weierophinney> and ralphschindler as well...?
[19:05] <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.
[19:05] <weierophinney> PadraicB, any thoughts?
[19:05] <PadraicB> Well, my idea is pretty much the same as Thinkscape's ;)
[19:05] <weierophinney> or anybody else?
[19:06] <weierophinney> PadraicB, which is?
[19:06] <PadraicB> We use a Configuration object to replace the typical array parameter
[19:06] <ralphschindler> i'm still undecided on having dependencies in the constructor
[19:06] <weierophinney> PadraicB, right... but what about hard dependencies and/or dependencies with defaults?
[19:08] <ralphschindler> does this mean options are public parameters?
[19:08] <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)
[19:08] <weierophinney> PadraicB, that's actually a good example of where a "sane default" might be implemented.
[19:08] <Thinkscape> ralphschindler: options CAN be public parameters on config-obj if they are scalar and not-validated.
[19:09] <weierophinney> Perhaps a factory in that particular case?
[19:09] <Thinkscape> ralphschindler: otherwise, set/getters.
[19:09] <PadraicB> ralphschindler, optionally. Though the explicit method is via setter/getter (public props would route back to those)
[19:09] <PadraicB> https://github.com/padraic/zf2/blob/1dafd898d68b479feedb78b1ea2634c9854747fd/library/Zend/Stdlib/Configuration.php
[19:09] <PadraicB> As a *rough* prototype for a base class
[19:09] <Thinkscape> is there any 5th option you guys are considering ? PadraicB mentioned discussion on "interface injection". Can you elaborate?
[19:10] <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)
[19:10] <weierophinney> Thinkscape, that would be via DI, and ralphschindler can discuss.
[19:11] <weierophinney> PadraicB, that looks good.
[19:11] <ralphschindler> it seems as though we favor the ability to automatically load sane dependencies (Defaults)
[19:11] <weierophinney> (the base class)
[19:11] <ralphschindler> currently new Zend\Di loads a default RuntimeDefinition and default InstanceManager, for example
[19:12] <ezimuel> PadraicB, very nice!
[19:12] <weierophinney> So, to me, I'm hearing Option 4 of the comparison, with the potential for dealing with "sane defaults" via setter injection?
[19:12] <Spabby> +1
[19:13] <PadraicB> ralphschindler, makes sense - so these would not enter via the constructor then? Optionally over-ridable via a setter instead?
[19:13] <ralphschindler> PadraicB: correct
[19:13] <ralphschindler> and tools like Di container would know dependencies based off whats listed in the interface
[19:14] <benjamin-gb> hi
[19:14] <PadraicB> ralphschindler, so what's left (if anything) to go into the constructor?
[19:14] <ralphschindler> just the Parameter object
[19:14] <ralphschindler> optionally of course
[19:14] <PadraicB> Well, I don't see any problem with that (better vote before I think about it now ;))
[19:15] <ralphschindler> it keeps the usage story very simple, and a consistent out of box experience
[19:15] <weierophinney> ralphschindler, would you expect that we'd always use setter injection over constructor injection?
[19:16] <weierophinney> or only for objects for which we can select sane defaults?
[19:17] <Thinkscape> Ok. How about w refactor a few components to show it off?
[19:17] <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?
[19:17] <ralphschindler> always prefer it for component classes (the main class)
[19:17] <ralphschindler> but relax the requirement for other classes in the component?
[19:18] <Thinkscape> tgodar: hard dependencies are satisfied during construction. otherwise you get fatal error.
[19:18] <ralphschindler> so that at least Zend\View\View's usage is consistent with Zend\Di\Di ?
[19:18] <weierophinney> you mean z
[19:18] <Thinkscape> tgodar: __construct(Adapter $adapter) --- you need a valid $adapter to make ti work.
[19:18] <tgodar> gotcha
[19:18] <weierophinney> Zend\View\PhpRenderer, right, ralphschindler? ;-)
[19:18] <weierophinney> zomg, are we reaching consensus? :)
[19:18] <Thinkscape> Ok, we have to move on.
[19:19] <Thinkscape> Let's refactor a few components
[19:19] <ralphschindler> i think when it comes to component configuration, i think we have a concencus
[19:19] <Thinkscape> could we see i.e. HTTP refactored with that ?
[19:19] <ralphschindler> Thinkscape: i think so
[19:19] <Thinkscape> We'll put it to final review on ML...
[19:19] <Thinkscape> Great!
[19:19] <ralphschindler> Zend\Di is already exactly that
[19:19] <Thinkscape> now
[19:19] <Thinkscape> "A quick talk and decision on what to do with "extra components"
[19:19] <Thinkscape> Extra components are those, which are not inside "CORE"
[19:20] <Thinkscape> or MVC
[19:20] <Thinkscape> For example: services
[19:20] <Thinkscape> Dojo
[19:20] <Thinkscape> Infocard
[19:20] <intiilapa> Thinkscape: extra components or not in standard distribution?
[19:20] <Thinkscape> and such
[19:20] <PadraicB> Assign all there issues to Artur Bodera?
[19:20] <PadraicB> :P
[19:20] <intiilapa> standard distribution != core + MVC
[19:20] <Thinkscape> Wait...
[19:20] <Thinkscape> there is a standard distribution -- this will contain something we call "standard"
[19:21] <Thinkscape> as bogus as this is
[19:21] <Thinkscape> also - we'll have COMPLETE/full distribution
[19:21] <weierophinney> Thinkscape, less editorial. :)
[19:21] <Thinkscape> But there is an alternative
[19:21] <Thinkscape> we can ship something we call "standard distribution" that will be thin, by definition.
[19:21] <weierophinney> intiilapa, we're referring to this RFC, btw: http://framework.zend.com/wiki/pages/viewpage.action?pageId=43745438
[19:21] <Thinkscape> And package all the rest of Zend\* namespace into downloadable packages for on-demand installation
[19:22] <weierophinney> standard distribution =  "Core" + "DB and Data Formats" + "Security" + "I18n/L10n" + "MVC"
[19:22] <Thinkscape> including everything under Zend\Sevice\*
[19:22] <PadraicB> Thinkscape: PEAR/Pyrus/Composer <- whichever is selected that *is* the plan (except for standard being too thin)
[19:22] <weierophinney> Right, so the question is really: do we keep them under library/ for now, or push them into a different hierarchy?
[19:22] <PadraicB> I think
[19:23] <Thinkscape> Basically - each service is a package you can fetch on-demand with:   #zf install service-gdata    or #zf install service-recaptcha
[19:23] <weierophinney> PadraicB, agreed.
[19:23] <intiilapa> maybe strange to have captacha out of form / mvc
[19:23] <intiilapa> -a
[19:23] <PadraicB> We need to bear in mind the categories are metatags, presumably, for whichever package installer is used.
[19:23] <weierophinney> intiilapa, I'd argue in that case that the Captcha form element moves into the unsupported area.
[19:23] <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?
[19:24] <intiilapa> weierophinney: ok, but it's a commun feature on the web now
[19:24] <weierophinney> rdohms, like it is today. There would be tooling to create an application skeleton.
[19:24] <weierophinney> intiilapa, outside the scope of this discussion.
[19:24] <intiilapa> rdohms: symfony standard comes with some bundles
[19:24] <rdohms> so where does "library" fit in?
[19:25] <PadraicB> rdohms, library is what it always been - a collection of classes.
[19:25] <weierophinney> rdohms, um, that's where code is installed...
[19:25] <tgodar> so the reasoning is because these will not be completely refactored in time... or to divide on components that are more 'optional'
[19:25] <PadraicB> MVC architecture can be generated to use the library (Symfony just let you download both at once...sort of)
[19:25] <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?
[19:26] <tgodar> what is the real objective?
[19:26] <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..
[19:26] <intiilapa> library is for vendor codes like Zend Framework and/or Symfony2
[19:26] <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
[19:26] <intiilapa> library is a folder of the app
[19:27] <weierophinney> rdohms, where are you downloading from? because all packages on framework.zend.com have a library directory
[19:27] <EvanDotPro> we can just maintain a list on the wiki of which is/isn't ready for release.
[19:27] <weierophinney> PadraicB, okay -- so keep them in, but have the packaging script omit them?
[19:27] <mascker> weierophinney: agree. Keep them in the same tree
[19:27] <PadraicB> weierophinney, exactly.
[19:27] <ezimuel> same tree for me
[19:28] <intiilapa> EvanDotPro: how months before release?
[19:28] <weierophinney> kk, so we simply need to maintain that info.
[19:28] <PadraicB> If we move them out and stigmatise them, they'll never be fixed anyway IMO. Might as well delete them at that point.
[19:28] <Akrabat> I'd prefer them out of the tree personally, so that it's clear what's 'done'
[19:28] <EvanDotPro> intiilapa: we can establish a more detailed process for it at a later time.
[19:28] <weierophinney> intiilapa, I'd argue we prune them at RC time?
[19:28] <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?
[19:29] <Akrabat> though presumably, we'll have a system when building docs that ignores the "not done" stuff
[19:29] <weierophinney> hey, all, there's another aspect to this: testing
[19:29] <PadraicB> hhatfield, everything up for BC breaks until it enters a stable distributed release ;)
[19:29] <EvanDotPro> oh good point weierophinney
[19:29] <weierophinney> Although we can address that with phpunit.xml + "@group disable"
[19:29] <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.
[19:29] <Akrabat> weierophinney: testing is essentially same issue as doc creation
[19:29]  * rdohms realizes how long its been since he downloaded ZF not using the svn
[19:29] <weierophinney> Perhaps somebody could go through and add an "@group disable" annotation to all components that we've marked as "other" for now?
[19:29] <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
[19:29] <rdohms> ok nevermind me...
[19:30] <PadraicB> Thinkscape, possibly - though PEAR has encouraged using betas/devs - people may never check this.
[19:30] <weierophinney> Thinkscape, good point -- we can use annotations when creating packages, too.
[19:30] <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.
[19:31] <Thinkscape> But they will be marked accordingly ...
[19:31] <weierophinney> Thinkscape, yes, and they can remove those annotations in their own branch as they begin testing.
[19:31] <weierophinney> as for the manual, simply comment out sections we don't want to build.
[19:31] <Thinkscape> PadraicB: pear has the stability filter. So by default it will not download something marked as "alpha" or "broken-beyond-repair".
[19:31] <weierophinney> That's easy enough.
[19:31] <weierophinney> Thinkscape, correct.
[19:31] <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
[19:32] <weierophinney> ralphschindler, yep.
[19:32] <Akrabat> on the flip side, we'll get a lot of bug reports against stuff we know isn't 'good'
[19:32] <Thinkscape> One more thing - what happens to bug tracking for those?
[19:32] <Thinkscape> ZF2 Jira ?
[19:32] <Thinkscape> what about other, new components ?
[19:32] <PadraicB> Akrabat, and a lot of patches if people insist on fixing it - < upside ;)
[19:32] <weierophinney> Akrabat, potentially. But we can also prioritize those low... and those won't be in the actual release.
[19:32] <Akrabat> PadraicB: I like optimism :)
[19:33] <weierophinney> so, let me summarise:
[19:33] <weierophinney> * Keep the "unstable", lower priority packages in the tree
[19:33] <weierophinney> * Have an annotation in classes that will not be shipped (or, vice versa, those that will)
[19:33] <weierophinney> * Mark tests for unshipped classes as "@group disable" or something simlilar that phpunit.xml knows to ignore
[19:34] <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.
[19:34] <weierophinney> * Comment out items in the manual.xml.in we won't ship
[19:34] <PadraicB> Not continually ignore them and leave them open for years...;)
[19:34] <hhatfield> would a "full" install include the "unstable" packages? or do they have to explicitly be installed?
[19:34] <weierophinney> Does that sound correct?
[19:34] <weierophinney> hhatfield, would not be shipped or packaged.
[19:34] <Thinkscape> weierophinney: please define "in the tree"
[19:34] <PadraicB> weierophinney, yes
[19:34] <Akrabat> The bit about commenting out in manual is really really important
[19:34] <rdohms> weierophinney: yes... the test thing might need a bit more details and reseach but that is the gist of it
[19:34] <PadraicB> hhatfield, no - they'd be omitted
[19:34] <weierophinney> Thinkscape,  under library/, tests/ etc. -- the current repo structure.
[19:35] <weierophinney> hhatfield, if you wanted them, you'd have to grab from git.
[19:35] <tgodar> what Akrabat said, would need to make very clear to existing users moving to ZF2 what is excluded
[19:35] <Thinkscape>  * Unmaintained packages are not distributed with ZF2, but obtainable on-demand via selected distro. mechanism (pear/pyrus...)
[19:35] <hhatfield> weierophinney: good. I think that would keep the bug report clutter down.
[19:36] <PadraicB> Thinkscape, time?
[19:36] <Thinkscape> Next one is huge
[19:36] <Thinkscape> but important
[19:36] <Thinkscape> _MODULES_
[19:36] <Thinkscape> Short intro
[19:36] <PadraicB> ZUNDLES :P
[19:36] <Thinkscape> Modules are not what ZF1 modules are
[19:37] <Thinkscape> Modules by current "draft" are packages
[19:37] <weierophinney> Thinkscape, why? that involves extra packaging effort.
[19:37] <Thinkscape> they can tie into MVC or not
[19:37] <weierophinney> (referring to your last point above)
[19:37] <weierophinney> You added that without discussion
[19:37] <Thinkscape> wait up :)
[19:37] <Thinkscape> They are a generalization of what ZF1 modules were.
[19:37] <EvanDotPro> Okay, let's cover weierophinney quickly then circle back to modules. :)
[19:37] <PadraicB> brb
[19:37] <Thinkscape> There will be "modules" that are not related to mvc
[19:37] <weierophinney> Thinkscape, basically, why would we package things we don't support?
[19:37] <EvanDotPro> (once Thinkscape finishes his thought)
[19:38] <weierophinney> Thinkscape, back up, please.
[19:38] <weierophinney> You added an item that we didn't discuss!
[19:38] <Thinkscape> ok
[19:38]  * rdohms slams on the handbrake
[19:38] <Thinkscape> If we don't know what modules are , how can we discuss module manager?
[19:38] <weierophinney> 1) why would we package them? and (2) if we did, wouldn't we need a way of indicating its unstable?
[19:38] <EvanDotPro> Thinkscape: weierophinney had suggested we just have unsupported components available via git, and skip packaging until they're considered "ready"
[19:39] <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.
[19:39] <intiilapa> I think we can't package a component with broken/skipped tests
[19:39] <weierophinney> intiilapa, +1
[19:40] <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.
[19:40] <Akrabat> I agree. "unstable" components shouldn't be packaged
[19:40] <Thinkscape> The purpose of packaging half-working stuff is for other people to be able to obtain in.
[19:40] <Thinkscape> Git is not a good choice
[19:40] <rdohms> weierophinney: how bout providign a git repository and using something like symfony's bin/vendor .. it basically just downloads from that git repo
[19:40] <weierophinney> Thinkscape, why not?
[19:40] <Akrabat> if you want to use unstable, then you need the git as we want pull requests
[19:40] <Thinkscape> Git is not a packagins mechanism.
[19:41] <weierophinney> Thinkscape, agreed, but then, these are ready packages!
[19:41] <rdohms> imho these do not need "packaging" they only need distribution
[19:41] <Akrabat> we don't want "non-devs" using broken stuff and thinking that's how ZF2 rolls
[19:41] <weierophinney> Akrabat, +1
[19:41] <Spabby> Akrabat: +1
[19:41] <weierophinney> rdohms, how would you accomplish distribution without packaging?
[19:42] <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?"
[19:42] <rdohms> weierophinney: define packaging
[19:42] <rdohms> like Bundles in sf .. they don't need packaging.. just download and install
[19:43] <intiilapa> we should improve the quality with continous integration behavior (build docs, php lint, all unit tests should be green, etc.)
[19:43] <PadraicB> rdohms, packaging is a protocol describing a download source and a method of installing that source on a local filesystem
[19:43] <PadraicB> Bundles are packages ;)
[19:43] <weierophinney> rdohms, bundles still need packaging; they simply have a mechanism for it.
[19:43] <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
[19:43] <weierophinney> Spabby, +1
[19:43] <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.
[19:44] <Thinkscape> What is the threshold then ?
[19:44] <rdohms> ok i can see my concepts were wrong, carry on
[19:44] <Spabby> 0 failed tests
[19:44] <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
[19:44] <Spabby> for a starting point
[19:44] <Thinkscape> ok
[19:44] <hhatfield> Spabby: how do we handle class dependencies in different parts of the tree?
[19:45] <Thinkscape> Back to the subject - a ZF2 module is a package with classes and other files that talk to other modules and Zend\* classes.
[19:45] <rdohms> i think it needs 2 checks: 0 failing tests plus a human "itsready" from the responsible dev ...
[19:45] <Thinkscape> Module manager is used to handle dependencies between those.
[19:45] <rdohms> we can have 0 failing tests but partial funcionality
[19:45] <PadraicB> hhatfield, via the packaging protocol (e.g. PEAR's deps resolver)
[19:45] <rdohms> which is not good
[19:45] <weierophinney> rdohms, we're all agreed at this point. Thinkscape has moved on. :)
[19:45] <Akrabat> "stable" components are ones we're prepared to support and bug fix
[19:45] <intiilapa> we should review all unit tests (a lot skipped or failed actualy)
[19:46] <PadraicB> P.S. the Module Manager implements a Package Protocol (in a sense - need to differentiate between the two)
[19:46] <intiilapa> PadraicB: +1
[19:46] <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.
[19:46] <Thinkscape> -----------
[19:46] <Thinkscape> now
[19:46] <Thinkscape> module manager
[19:46] <Thinkscape> http://framework.zend.com/wiki/display/ZFDEV2/2011-09-14+Meeting+Agenda
[19:46] <intiilapa> like phing implement pear package, pear2 package, and phar package
[19:46]  * rdohms is as lost as a blind man in a shootout
[19:46] <EvanDotPro> Thinkscape: and the instatiation / configuration of them.
[19:46] <Thinkscape> here is a shortlist of what it should be able to do
[19:46] == Akrabat has changed nick to Akrabat|away
[19:46] <PadraicB> rdohms :P
[19:47]  * weierophinney waits for the list...
[19:47] <Thinkscape> Please notice a few things -- multiple distribution backends. ..
[19:47] <EvanDotPro> s/instatiation/instantiation
[19:47] <Thinkscape> and sources
[19:47] <intiilapa> module manager must be aware of installation (install db, migration db, asset available, etc.)
[19:47] <Thinkscape> A module can be as big as Magento or as small as a _single_ db adapter for Zend\Db.
[19:48] <intiilapa> Thinkscape: yes
[19:48] <Thinkscape> Looking at that list --- is there anything missing?
[19:48] <tgodar> http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+ZF2+Modules
[19:48] <Thinkscape> Is there anything, that should not be handled ?
[19:49] <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)
[19:49] <Thinkscape> -- the list is at: http://framework.zend.com/wiki/display/ZFDEV2/2011-09-14+Meeting+Agenda - scroll to "Module Manager"
[19:49] <Thinkscape> non-ZF apps can still use them
[19:50] <Thinkscape> for example
[19:50] <Thinkscape> classes are PSR0 compatible - you can autoload them
[19:50] <Thinkscape> js/img/ etc assets are just files - you can copy them over or link
[19:50] <weierophinney> PadraicB, basically, the Module Manager automates tasks that can otherwise be done manually
[19:50] <intiilapa> Thinkscape: default loader is classmap + autotload PSR0?
[19:51] <weierophinney> intiilapa, that's up to the developer.
[19:51] <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.
[19:51] <weierophinney> intiilapa, there's a factory for that.
[19:51] <Thinkscape> alextech: we want to have a both route override and extension ... and priorities
[19:51] <ralphschindler> if we have a clear entry point, i don't see why we need to enforce a directory structure
[19:51] <Thinkscape> alextech: for example: if there are modules and sub-modules that override some behaviors of parent modules.
[19:51] <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.
[19:51] <EvanDotPro> ralphschindler: +1
[19:51] <PadraicB> I got lost - what is the current topic?
[19:52] <PadraicB> Directory struct?
[19:52] <Thinkscape> PadraicB: Module Manager - what should it do?
[19:52] <ralphschindler> module manager, yes
[19:52] <PadraicB> Okay then. From the list...
[19:52] <PadraicB> Handle multiple installatin methods. Anyone disagree?
[19:52] <EvanDotPro> be careful here, since this topic will likely determine my workload over the coming weeks ;)
[19:53] <PadraicB> hehe
[19:53] <PadraicB> Still waiting for -1s...
[19:53] <ralphschindler> what are you addressing PadraicB (from the list?)
[19:54] <Rvl> why not only app specific modules, otherwise I think there will be too much abstraction
[19:54] <EvanDotPro> ralphschindler: #1 from the "Module Manager goals" on the meeting agenda
[19:54] <PadraicB> 1st point under Module Manager goals http://framework.zend.com/wiki/display/ZFDEV2/2011-09-14+Meeting+Agenda
[19:54] <ralphschindler> ok
[19:54] <rdohms> +1
[19:54] <EvanDotPro> Rvl: have you looked over my current module manager prototype?
[19:54] <ralphschindler> is module manager a runtime component or a development time tool?
[19:54]  * Thinkscape gives direct link: http://framework.zend.com/wiki/display/ZFDEV2/2011-09-14+Meeting+Agenda#2011-09-14MeetingAgenda-ModuleManagergoals
[19:55] <PadraicB> Right, the silent majority are...silent. Assuming you all voted +1
[19:55] <Thinkscape> ralphschindler: both
[19:55] <weierophinney> ralphschindler, both, definitely
[19:55] <PadraicB> Second point, Handle multiple installation sources? Anyone disagree
[19:55] <Thinkscape> ralphschindler: if a module is "installed" by copying it over to the tree, then a Module Manager scanner have to be involved
[19:55] <weierophinney> ralphschindler, the idea is that you can use it in your bootstrap, or you could invoke it frm a script.
[19:55] <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.
[19:55] <Thinkscape> ralphschindler: otherwise, it will be invoked from CLI or WebInstallator
[19:55] <weierophinney> PadraicB, +1
[19:56] <PadraicB> Any -1s?
[19:56] <rdohms> PadraicB: +1 should read from a config file
[19:56] <Rvl> EvanDotPro:  I'm not up to date with the current state of it. Probably my topic was not ontopic
[19:57] <PadraicB> Rvl, no worries - it's a complicated and busy topic in ZF2. Even I can't track all of it ;)
[19:57] <PadraicB> Assuming the silent majority assents...
[19:57] <PadraicB> Third point, Handle two installation styles: "local installation" and "shared-dir installation"? Anyone disagree?
[19:57] <ralphschindler> i think module sources and methods are largely non-factors as you're using 3rd party tools to transfer the code anyway
[19:57] <ralphschindler> if we're talking about reinventing packaging/distribution mediums, I'm -1
[19:57] <ezimuel> ralphschindler, +1
[19:57] <EvanDotPro> +1 to the third point, my current prototype already supports this.
[19:58] <PadraicB> ralphschindler, has a bearing later on the management tool though.
[19:58] <Thinkscape> ralphschindler: +1 there will be helper tools though. For example #zf install X  
[19:58] <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)
[19:58] <rdohms> PadraicB: -1 shared dir feels like its too personal
[19:58] <ralphschindler> what is "shared dir" ?
[19:58] <PadraicB> weierophinney, we can park it for now. If we support local installs - it can be figured out in time
[19:58] <weierophinney> yep
[19:59] <ralphschindler> like, multiple projects sharing modules?
[19:59] <PadraicB> ralphschindler, like PEAR's main director /usr/share/php or whatever
[19:59] <EvanDotPro> ralphschindler: correct
[19:59] <ralphschindler> it seems as though this too is transparent to the module manager
[19:59] <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)
[19:59] <epoleacov> But what about local storage for ModuleManager, means storage of information which modules installed, etc.?
[20:00] <ralphschindler> if you give it a path to a shared resource or an in-project resource, the end is the same, no?
[20:00] <Thinkscape> epoleacov: local cache per-app
[20:00] <PadraicB> rdohms, it would be optional. For Modules, the default would be per-app I assume.
[20:00] <rdohms> i dont like the ideia of modmanager ending up as pear ... it should be objective and concise
[20:00] <EvanDotPro> epoleacov: you would override the config for the "shared" module and point it to a local storage point.
[20:01] <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)
[20:01] <weierophinney> rdohms, not sure what you're getting at...
[20:01] <Thinkscape> rdohms: Mod Manager will not replace nor try to imitate distribution system.
[20:01] <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 ;)
[20:01] <rdohms> Thinkscape: yes but once it starts doing shared-dir and tracking states, and etc.. it will start doing too much
[20:02] <prolic> rdohms +1
[20:02] <Thinkscape> what do you mean "too much" ?
[20:02] <weierophinney> rdohms, shareddir is really only about whether or not the module manager cares where the module is installed
[20:02] <PadraicB> rdohms, it will nothing that you couldn't do manually.
[20:02] <weierophinney> i.e., does it have to be in the same project tree?
[20:02] <EvanDotPro> shared dir is nothing more than a path.
[20:02] <weierophinney> I see it as a non-issue, tbh
[20:02] <tgodar> we got rsync... think move on
[20:03] <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)
[20:03] <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 :)
[20:03] <EvanDotPro> Thinkscape: +1
[20:03] <tgodar> err symbolic links... path local shared seems non issue
[20:03] <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
[20:03] <Thinkscape> rdohms: you will have to manually configure it
[20:04] <Thinkscape> (application config)
[20:04] <EvanDotPro> rdohms: look over the ModuleCollection and ModuleLoader classes here: https://github.com/EvanDotPro/zf2/tree/prototype/mvc-module/modules/Zf2Module/src/Zf2Module
[20:04] <PadraicB> Fourth point: Perform on-demand loading of modules (via call or combined with spl autoloader)?
[20:04] <rdohms> i'll look inot it and bring it up in the ML if need be
[20:04] <PadraicB> EvanDotPro, you're the resident expert here apparently? ;)
[20:04] <ralphschindler> -1 on all things Module Manager related to the act of "installing"
[20:04] <weierophinney> PadraicB, what does that mean, exactly? As in Runtime? I believe we already have that...
[20:05] <rdohms> on-demand loagins is just autolaod, or bootstrap?
[20:05] <weierophinney> ralphschindler, can you elaborate? I think by "install", we're talking getting configuration out, public assets out...
[20:05] <PadraicB> ralphschindler, so what installs Modules? My aching fingers at 11pm?
[20:05] == TEST_TESTER has changed nick to gcheung
[20:05] <weierophinney> PadraicB, LOL
[20:05] == Akrabat|away has changed nick to Akrabat
[20:05] <ralphschindler> by install i mean the act of putting code in the proper place initially- not asset managment
[20:06] <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
[20:06] <tgodar> as someone who does not use tool I like that
[20:06] <Thinkscape> ralphschindler: Manager will not move modules' files
[20:06] <Thinkscape> ralphschindler: it will just scan them and report back what is available...
[20:06] <PadraicB> prolic +1, EvanDotPro has a Module Manager in prototype that is looking good.
[20:07]  * EvanDotPro takes note to change ModuleCollection to ModuleManager
[20:07] <PadraicB> ralphschindler, want to raise your objections on the ML? For those voting -1, we'll bring the topics back next meeting.
[20:08] <EvanDotPro> currently, it doesn't even do any scanning. It only cares about what modules have been "asked for"
[20:08] <ralphschindler> yeah - i think there are too many unknowns at the moment
[20:08] <ralphschindler> a lot of this stuff talks about Zend_Tool and a "zf environment" but we don't know what those look like exactly
[20:08] <PadraicB> ralphschindler, agreed.
[20:08] <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
[20:08] <weierophinney> ralphschindler, the discussion so far has not included having the MM do any installation tasks, only discovery.
[20:08] <ralphschindler> is a project ZF enabled? is the users home directory ZF enabled?
[20:08] <ralphschindler> etc
[20:08] <PadraicB> Point 5: Handle discovering, registering, loading and merging of: LOTS OF STUFF ;) Anyone disagree?
[20:08] <Rvl> or am I completely missing the point
[20:09] <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."
[20:09] <weierophinney> Rvl, you haven't been following the ML, clearly. :)
[20:09] <EvanDotPro> Rvl: what overhead is being proposed?
[20:09] <weierophinney> PadraicB, I'm +1
[20:09] <PadraicB> Rvl, the overhead is simple automation of all those manual steps.
[20:09] <Rvl> running some sort of install.php seems pretty straightforward to me :)
[20:10] <epoleacov> yeah, but some modules require actions after installtion and before ready to work.
[20:10] <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.
[20:10] <PadraicB> Anyone commenting on Point 5?
[20:11] <hhatfield> question about the items marked "if MVC module…". Is that specifically talking about the ZF2 MVC?
[20:11] <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.
[20:11] <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.
[20:11] <weierophinney> epoleacov, for those, we'll likely have some functionality.
[20:11] <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.
[20:11] <PadraicB> hhatfield, yes - presumable referring to Modules using MVC stuff like controllers/views
[20:11] <EvanDotPro> PadraicB: i think point 5) is almost entirely handled by the current init()
[20:11] <weierophinney> hhatfield, yes
[20:11] <prolic> point 5: discovering, registering and merging: is it meant as runetime task or installation task?
[20:11] <weierophinney> Thinkscape, agreed
[20:12] <weierophinney> prolic, either and/or both. :)
[20:12] <ralphschindler> Thinkscape: now we have a module infrastructure that REQUIRES devtime tooling
[20:12] <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.
[20:12] <PadraicB> prolic, both - though for production a once-off task would create caches (better performance)
[20:12] <prolic> the cache could also be done during installation
[20:13] <PadraicB> ralphschindler, no - the tooling can be ignored but then you'd lose efficiency.
[20:13] <ralphschindler> so is there a module frontend to manage modules that is a module?
[20:13] <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.
[20:13] <ralphschindler> or, does the default ZF application have this already baked in?
[20:13] <PadraicB> ralphschindler, can't wait for someone to write that...
[20:13] <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".
[20:13] <ralphschindler> you see my point though-
[20:13] <tgodar> implies install/modify/uninstall
[20:14] <ralphschindler> Drupal is not a blank application stack, its a cms platform
[20:14] <ralphschindler> so, in my mind, its not a good comparison
[20:14] <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
[20:14] <Thinkscape> ralphschindler: that proves my point - it's more complex at this moment, yet it manages it very nicely.
[20:14] <PadraicB> ralphschindler, I don't build blank application stacks however... The caching/compiling does help.
[20:14] <ralphschindler> but i wouldn't want to write an application on drupal- as its already too opinionated on how things are done
[20:14] <PadraicB> Anyway, any firm -1 to point 5? Otherwise:
[20:15] <PadraicB> Point 6: Manage static assets (module's directory is immutable, its assets are copied/linked to application's main public/)
[20:15] <PadraicB> ralphschindler, you think ZF is unopinionated???
[20:15] <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
[20:16] <ralphschindler> PadraicB: more or less, i've seen user auth systems written 100 different ways :)
[20:16] <prolic> about immutable assets: I use the dojo build system for css very often, so -1 to immutable css
[20:16] <weierophinney> ralphschindler, we can leave that flexible by using an EventManager (which is how EvanDotPro has already coded it)
[20:16] <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.
[20:16] <EvanDotPro> weierophinney: +1, i left it open-ended like this for this exact reason.
[20:16] <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
[20:16] <PadraicB> Assuming NOBODY is -1 on managing static assets. Yes, you can still do it manually if you really want to ;)
[20:16] <Thinkscape> S2 doesn't require cli for that either.
[20:17] <Rvl> agreeds with ralphschindler -1
[20:17] <weierophinney> PadraicB, the bigger question on point 6 is: do we code it, or delegate it to 3rd party tools?
[20:17] <ralphschindler> i think asset management needs some good planning on its own :)
[20:17] <weierophinney> Regardless, we can likely provide hooks or events for it.
[20:17] <Akrabat> I may be -1 on 6.
[20:17] <Akrabat> I think it needs more understanding of how it would work in practice
[20:18] <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.
[20:18] <weierophinney> Akrabat, agreed, but I'd still claim it's something the MM should likely assist with.
[20:18] <prolic> +1 on 6 when on ModuleInstaller, not on ModuleManager
[20:18] <ralphschindler> ok EvanDotPro
[20:18] <intiilapa> what means S2?
[20:18] <PadraicB> prolic, it would be an install task (or manual do-by-hand task)
[20:18] <PadraicB> S2 is Symfony 2
[20:18] <Akrabat> weierophinney: that's possible. I also like the idea of leaving it to a cli installer or manual installation readme
[20:18] <prolic> PadraicB, ok
[20:19] <Akrabat> but as I say, atm, I have don't have a clear view on how it would work :)
[20:19] <PadraicB> So tentative maybe needing more ML examples/prototyping?
[20:19] <weierophinney> PadraicB, yes
[20:19] <PadraicB> cool
[20:19] <ralphschindler> yes, we need more prototyping here
[20:19] <Akrabat> yep
[20:19] <PadraicB> Point 7: Handle modules registry
[20:19] <rdohms> Akrabat: take a look at assetic and Sf2 it will shine some light
[20:19] <ralphschindler> the more infrastucure we build, the more of a performance impact it will have
[20:19] <PadraicB> I'm looking at this sideways. Thinkscape?
[20:20] <ralphschindler> se we need to balance what happens during runtime vs. the dev time tools
[20:20] <weierophinney> I have _no_ clue what point 7 is about; first we've really talked about a module registry...
[20:20] <ralphschindler> there are still people on windows without a real CLI prompt ;)
[20:20] <Thinkscape> ralphschindler: that is a challenge we'll tackle. I strongly believe in cache-early and going KISS.
[20:20] <weierophinney> back on-topic: what is point 7 about?
[20:20] <Thinkscape> also - ZF2 modules will _not_ require cli to function
[20:20] <PadraicB> ralphschindler, don't be silly. They have MSDOS. It's really good. (I disclose MS paid me to say that :P)
[20:20] <Akrabat> I don't understand point 7 either
[20:21] <PadraicB> Okay, skipping for now.
[20:21] <Akrabat> ralphschindler: windows people have php.exe too :)
[20:21] <ralphschindler> -1 on #7
[20:21] <ralphschindler> haha, yeah Akrabat
[20:21] <tgodar> 7 is module specific registry?
[20:21] <Thinkscape> 7. mod manager will handle module's metadata cache.
[20:21] <alextech> registry with vars only within the scope of module maybe?
[20:21] <Thinkscape> this is for 8. and 9.
[20:21] <PadraicB> Ahh, you mean a record of what Module's are installed?
[20:21] <EvanDotPro> Thinkscape: so provide a proxy to the modules Module classes?
[20:22] <Thinkscape> EvanDotPro: not really
[20:22] <Thinkscape> Zend\Module\Manager::isLoaded('SEO');
[20:22] <Thinkscape> Zend\Module\Manager::isAvailable('SEO')
[20:22] <Thinkscape> Zend\Module\Manager::isInstalled('SEO')
[20:22] <weierophinney> Thinkscape, why is this necessary?
[20:22] <Thinkscape> Zend\Module\Manager::init('SEO')
[20:22] <PadraicB> EvanDotPro, that would work but not if installed to a shared directory probably. Hard question...
[20:22] <Thinkscape> for debuggin, testing and explicit loading
[20:22] <weierophinney> I'd not expect to test for that stuff in application code -- only the classes...
[20:22] <ralphschindler> -1 on 8
[20:22] <ralphschindler> you'll get an exception if you run into a situation where things are missing
[20:23] <EvanDotPro> PadraicB: it would work in a shared directory just fine with how the module loader works now.
[20:23] <weierophinney> Thinkscape, can you explain a bit more?
[20:23] <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.
[20:23] <weierophinney> Where would this code be called?
[20:23] <ralphschindler> there's no need that every request should check for the existence of a module
[20:23] <EvanDotPro> (not saying i'm +1, just clarifying the current functionality)
[20:23] <Akrabat> 8 feels like a installation issue
[20:23] <ralphschindler> +1 on weierophinney's question
[20:23] <weierophinney> Thinkscape, check on whether a class exists, not whether or not the module is there... if (!get_class('GeoIp\Some\Functionality')) { // bail }
[20:24] <PadraicB> EvanDotPro, hmm - cool if true! (Must read more of your code!)
[20:24] <Thinkscape> weierophinney: module is not only a collection of classes
[20:24] <Thinkscape> you might need to init() geoip before it works.
[20:24]  * EvanDotPro gets the feeling a lot of people haven't read through my current module prototype :-p
[20:24] <PadraicB> EvanDotPro :P
[20:25] <EvanDotPro> i can almost guarantee this part of the meeting would have gone much smoother otherwise ;)
[20:25] <epoleacov> i think not good idea to check class existing, possible better to use messagin system, and if mesaage to registered disable functionality.
[20:25] <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
[20:25] <prolic> EvanDotPro - for our excuse, it was a short time between your release and this meeting, I had only time for a shorter look
[20:25] <PadraicB> Point 8: Handle simple module dependencies (those which have not been not handled by Pear/Pyrus, i.e. via manual installation)
[20:26] <ralphschindler> EvanDotPro: looking at user-module and guestbook modules
[20:26] <EvanDotPro> prolic: very true, that's valid :)
[20:26] <PadraicB> Though it's already mentioned - any -1s and reasons?
[20:26] <prolic> point 8: what is a simple and what is a complex dependency?
[20:26] <weierophinney> prolic, untrue. It's been working since late last week. :)
[20:26] <PadraicB> brb - someone post pt 9 in a few
[20:26] <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.
[20:26] <EvanDotPro> weierophinney: well it's relative to what "short time" is, since it was only 1 weekend.
[20:27] <weierophinney> EvanDotPro, I was being facetious. :)
[20:27] <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.
[20:27] <weierophinney> Thinkscape, again, though, currently that metadata becomes part of application configuration (i.e., injected via DI).
[20:28] <intiilapa> module manager are a component in the library?
[20:28] <Thinkscape> intiilapa: yes
[20:28] <weierophinney> So, I'm not sure we need the capabilities -- simply have dependencies.
[20:28] <prolic> so module x depending on module y, i will install module x and fail because module y is missing? is this too complex?
[20:28] <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?
[20:28] <weierophinney> prolic, a package manager would take care of installing dependencies.
[20:28] <Akrabat> I don't really understand 8 I think. Doesn't the installer worry about dependent modules?
[20:28] <intiilapa> ralphschindler: Information.php file and/or composer.json
[20:28] <weierophinney> ralphschindler, minimal requirement is a Module class under the module namespace.
[20:28] <hhatfield> +1 Akrabat
[20:29] <ralphschindler> i thought it was Module.php ?
[20:29] <Akrabat> and if you don't use the installer, then you have to read the README file
[20:29] <weierophinney> intiilapa, s/Information/Module/
[20:29] <EvanDotPro> ralphschindler: currently the _only_ requirement is that it has a Module class in Module.php, and sets up it's owne autoloader
[20:29] <weierophinney> ralphschindler, it is.
[20:29] <weierophinney> intiilapa, composer.json is unnecessary, and going to be removed.
[20:29] <Akrabat> EvanDotPro: actually, it doesn't have to set up an autoloader
[20:29] <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()
[20:29] <EvanDotPro> and the autoloader is something we're looking at caching to prevent a plethora of autoloaders being registered every time.
[20:30] <EvanDotPro> true, it doesn't have to provide an autoloader; only if it needs to load some php classes.. automatically ;)
[20:30] <prolic> i could expect the moduleInstaller to ask me, if he should download module y via pyrus or whatever our default will be
[20:30] <epoleacov> but it related module has updated after installation, and functionallity was disappear?
[20:30] <Akrabat> EvanDotPro: exactly :)
[20:31] <prolic> I think ALL classes should be autoloadable from everywhere in your application, not neccessary to bootstrap a module first
[20:31] <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.
[20:31] <ralphschindler> so the most minimal requirement, and the only runtime implication is that for each module, Module->init() is called, right?
[20:31] <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.
[20:31] <Thinkscape> prolic: consider you have 100 modules in shared dir. You current application just needs 5 of them + 5 other, locally installed.
[20:32] <EvanDotPro> ralphschindler: even init() is optional.
[20:32] <Thinkscape> ralphschindler: the existence of init() is optional
[20:32] <PadraicB> Back to basics, what if anything was decided about point 8?
[20:33] <Thinkscape> if you install a db-adapter-firebird module, then it just provides autoloadable classes for \Zend\Db\Adapter *
[20:33] <Thinkscape> No need to init that.
[20:33] <PadraicB> ping ping ping
[20:33] <EvanDotPro> <?php namespace MyModule; class Module { } ?> is the minimum as it stands.
[20:33] <intiilapa> we have an interface for the module class?
[20:33] <prolic> when i'm in module x and want to load a class from module y, then i need to init module y first ?
[20:33] <weierophinney> PadraicB, nothing so far -- still in discussion.
[20:34] <Akrabat> prolic: no
[20:34] <weierophinney> intiilapa, no. Duck typing for now to discover if we need anything more.
[20:34] <Thinkscape> prolic: no, it will happen automagically
[20:34] <PadraicB> Back to the ML then? We're short on time by -4 minutes
[20:34] <Thinkscape> ok
[20:34] <Thinkscape> last one
[20:34] <Thinkscape> quick
[20:34] <Thinkscape> https://gist.github.com/1217290
[20:34] <weierophinney> prolic, autoloaders are setup before the application is executed -- meaning that when you need the class from module y, you can discover it.
[20:34] <Thinkscape> we're discussing how module directory structure should look like
[20:34] <prolic> ok
[20:34] <weierophinney> Thinkscape, -1 on that structure.
[20:35] <Thinkscape> Above are 2 examples of how it might look like
[20:35] <EvanDotPro> prolic: be sure to check out the module prototype when you have time.
[20:35] <Thinkscape> your comments?
[20:35] <weierophinney> Should follow PSR-0 internally
[20:35] <intiilapa> Thinkscape: app is different of a module?
[20:35] <Thinkscape> weierophinney: what for ?
[20:35] <weierophinney> so either have Statistics/Controller/..., or Statistics/src/Statistics/Controller/
[20:35] <ralphschindler> -1 on any required structure
[20:35] <Akrabat> I believe that there should be no requirements on structure
[20:35]  * EvanDotPro doesn't see any reason to force a structure.
[20:35] <Akrabat> it's entirely up to the module developer
[20:35] <weierophinney> but, really Akrabat+1
[20:35] <prolic> EvanDotPro: I will, and send you further feedback of course ;)
[20:35] <tgodar> agreed
[20:35] <EvanDotPro> prolic: thank you much :)
[20:36] <Akrabat> I think we could possibly provide a set of "conventions"
[20:36] <Thinkscape> There are reasons for consistent structure...
[20:36] <ezimuel> Akrabat +1
[20:36] <EvanDotPro> any "structure" we discuss should be purely for "convention" and/or "zf create module Foo"
[20:36] <Thinkscape> it helps with resolving, scanning and such
[20:36] <weierophinney> Thinkscape, the zf1-style structure has caused a ton of confusion, as well as issues with autoloading. That's my main reason.
[20:36] <Akrabat> especially around assets/tests/docs
[20:36] <EvanDotPro> Thinkscape: the only thing that needs to be resolved is Module.php, no?
[20:36] <intiilapa> I think we need an helper to merge all js and css in one file for the prod env, still the image assets
[20:36] <weierophinney> But, as ralphschindler, EvanDotPro, and Akrabat say, there's really no reason to enforce a structure.
[20:36] <Akrabat> Thinkscape: there shouldn't be any scanning/resolving. Module.php does all that
[20:37]  * Thinkscape changes topic: "What should a CONVENTION for a module dir structure look like?"
[20:37] <ralphschindler> Thinkscape: assumptions shouldn't be made, the module should have explicit maps by default, and be provided alternatives file maps as configuration
[20:37] <EvanDotPro> Thinkscape: much better
[20:37] <EvanDotPro> :)
[20:37] <weierophinney> intiilapa, that was talked about earlier. Move on. :)
[20:37] <Thinkscape> ralphschindler: this brings verboseness where it is not required
[20:37] <Akrabat> Thinkscape: :)
[20:37] <intiilapa> Thinkscape: what is the goal of your app dir? the app should be a module
[20:37] <weierophinney> Thinkscape, I'm creating an alternate gist...
[20:37] <Thinkscape> for example - I have 1 class Adapter\Firebird.php ---- do I need map for that ?
[20:38] <Thinkscape> or can I just put it into modules/firebird/src/Adapter/Firebird.php ?
[20:38] <Thinkscape> and this module will work?
[20:38] <ralphschindler> Thinkscape: that sounds like a library component ;)
[20:38] <Akrabat> Thinkscape: yes. How else will the DI find it to attach it to the DB?
[20:38] <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
[20:38] <EvanDotPro> ralphschindler: +1
[20:38] <Thinkscape> ralphschindler: you don't need Module.php for that
[20:38] <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
[20:38] <Akrabat> ralphschindler wrote it more nicely for me
[20:39] <weierophinney> Thinkscape, http://pastebin.com/PRuCzQsq
[20:39] <ralphschindler> for ZF modules, i'd say they always need a clear entry point, such as Module.php
[20:39] <ralphschindler> otherwise its just code in a directory
[20:39] <Thinkscape> you don't need any function calls... because I can assume:   \ModuleNamespace\Class.php  => /modules/Module/src/Class.php
[20:39] <ralphschindler> and no clear entry point
[20:39] <EvanDotPro> weierophinney: +1
[20:39] <ralphschindler> i am +1 on a suggested structure
[20:39] <ralphschindler> but we should not enforce a structure
[20:39] <weierophinney> ralphschindler, this is for a suggested structure.
[20:40] <weierophinney> not an enforced one
[20:40] <ralphschindler> some people might want to retrofit code into a module, etc
[20:40] <EvanDotPro> ralphschindler: the topic has been changed to suggested structure
[20:40] <weierophinney> I forgot to put Module.php in there.
[20:40] <prolic> +1 for default structure + abbility to override
[20:40] <Akrabat> Thinkscape: general assumption is that modules will prefer the classmap autoloader as it's so much faster than using the standard one
[20:40] <tgodar> prolic +1
[20:40] <Thinkscape> weierophinney: that's exactly what I've had in proposal 2
[20:40]  * Thinkscape points to https://gist.github.com/1217290 - scroll down
[20:40] <weierophinney> revised: http://pastebin.com/qE2JbFLY
[20:40] <weierophinney> Thinkscape, I hadn't seen the second proposal...
[20:41] <PadraicB> So we're sort of agreeing in principle to directory structure being a convention? Yes?
[20:41] <Rvl> Module/src/Module, why not Module/src/
[20:41] <Thinkscape> its there since begining :)
[20:41] <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 :)
[20:41] <weierophinney> Rvl, so that you can add src\Module as a directory to the StandardAutoloader
[20:41] <ralphschindler> thus making this structure (suggested)
[20:41] <Akrabat> I'm stronly against any automatic wiring
[20:41] <weierophinney> PSR-0 compliant
[20:41] <weierophinney> ralphschindler, +1
[20:41] <Thinkscape> Akrabat: how about calling it "default" wiring ?
[20:41] <Akrabat> on that revised one, why is Module.php outside of Statistics?
[20:41] <weierophinney> PadraicB, yes
[20:42] <EvanDotPro> Rvl: also to allow a module to contain >1 root namespace in a clean way, no?
[20:42] <Akrabat> Thinkscape: I'm still against it as it implies StandardAutoloader
[20:42] <weierophinney> Akrabat, CRAP! I messed up!
[20:42] <Akrabat> *phew*
[20:42] <intiilapa> weierophinney: Module.php is not inside the module?
[20:42] <weierophinney> Akrabat, here: http://pastebin.com/xUGuQCRS
[20:42] <weierophinney> intiilapa, it was supposed to be. I messed up. See previous. :)
[20:42] <Akrabat> that's better :)
[20:42] <intiilapa> ok
[20:43] <Akrabat> question: we're moving away from the .classmap convention to autoload_classmap?
[20:43] <Thinkscape> why is configs in Statistics ?
[20:43] <Akrabat> cos I'm definitely +1 to that
[20:43] <epoleacov> weierophinney: public under application dir?
[20:43] <Thinkscape> PSR-0 doesnt work with *.ini
[20:43] <intiilapa> autoload_* is related to a default behavior or the responsability of Module class?
[20:43] <ralphschindler> Akrabat: i think we need to, some ide's and editors don't show the . files
[20:43] <Thinkscape> public in Statictics?
[20:43] <weierophinney> Akrabat, some folks aren't liking the hidden files.
[20:43] <intiilapa> Thinkscape: Di, routes, etc.
[20:43] <alextech> if there may not be an mvc with a url pointing to the module, how will browser ever get to public?
[20:43] <Akrabat> ralphschindler, weierophinney: Good. I'm one of them :)
[20:43] <weierophinney> intiilapa, it's just an example.
[20:43] <Thinkscape> alextech: files will be merged/copied to app's public
[20:43] <Akrabat> alextech: that's the assets discussion we had earlier
[20:43] <ralphschindler> code paths shouldn't be hidden for debugging reasons alone (and others)
[20:43] <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
[20:44] <weierophinney> Thinkscape, those are module congifurations
[20:44] <EvanDotPro> (re: directory structure)
[20:44] <Thinkscape> alextech: (asset management)
[20:44] <PadraicB> Alright, it's 19:41 here so can we assume meeting over?
[20:44] <PadraicB> Hmm, my watch is slow...
[20:44] <weierophinney> EvanDotPro, that's basically exactly what I propose.
[20:44] <Akrabat> EvanDotPro: I prefer views under src tbh
[20:44] <Thinkscape> weierophinney: that doesn't make sense...
[20:44] <Akrabat> but I won't really mind
[20:44]  * Thinkscape calls it today - meeting is over ! THANK YOU!!
[20:44] <weierophinney> Thinkscape, I don't know if we're looking at the same thing
[20:45] <Thinkscape> Stay only if you want to :D :D :D
[20:45] <EvanDotPro> Akrabat: the cool thing is, in your modules you can do that, since modules will add their own view paths :)
[20:45] <Akrabat> yep
[20:45] <Thinkscape> ok, got the revised one http://pastebin.com/xUGuQCRS
[20:45] <Thinkscape> (gist is better because it versions)
[20:45] <ralphschindler> +1 on EvanDotPro
[20:45] <weierophinney> Thinkscape, I was trying to get across this: modules/Statistics/configs/...
[20:45] <Akrabat> PadraicB: yeah - meeting over.  Bikeshed discussion starting :)
[20:45] <weierophinney> Thinkscape, does that look better, then?
[20:46] <ezimuel> EvanDotPro +1
[20:46] <Thinkscape> weierophinney: so you're proposing: everything php goes PSR-0 style, everything else, plural-lowercased-dir ?
[20:46] <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 :D
[20:46] <ralphschindler> out of curiosity, how does the system know the namespace of the module?
[20:46] <weierophinney> Thinkscape, yes -- and PHP code under a "src" or "php" tree.
[20:46] <Thinkscape> and multiple namespaces under src - if module author wants to.
[20:46] <weierophinney> (or "lib" or "library"... something denoting it's source code)
[20:46] <Akrabat> ralphschindler: namespace of module = module directory name
[20:47] <weierophinney> Thinkscape, yes.
[20:47] <ralphschindler> so, it can be modules/Vendor/ModuleName ?
[20:47] <Thinkscape> open question: what about injecting Zend\* namespace?
[20:47] <Akrabat> ralphschindler: otherwise Statistics\Module gets difficult
[20:47] <ralphschindler> or will that break things?
[20:47] <intiilapa> Thinkscape: where?
[20:47] <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?
[20:47] <Thinkscape> for example Zend\Db\Adapter\Firebird extends Zend\Db\Adapter\Abstractadapter ?
[20:47] <Akrabat> ralphschindler: that should definitely work imo
[20:47] <ralphschindler> Thinkscape: no
[20:47] <ralphschindler> if you don't own the top level namespace, you shouldn't be using it
[20:47] <EvanDotPro> prolic: that's a question i raised in my readme which is TBD :)
[20:47] <weierophinney> prolic, I'd expect that would be something you setup at the application level
[20:48] <intiilapa> prolic: Di issue I think
[20:48] <tgodar>  look forward to seeing more code around MM - later all
[20:48] <prolic> good
[20:48] <Thinkscape> so Firebird\Firebirdadapter extends Zend\Db\Adapter\Abstractadapter ?
[20:48] <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.
[20:48] <Thinkscape> tgodar: thx. later!
[20:48] <weierophinney> Thinkscape, absolutely. :)
[20:49] <ezimuel> bye guys
[20:49] <Thinkscape> ------------------------ Thanks all! Keep prototypes coming! and ML alive
[20:49] <EvanDotPro> </meeting>
[20:49] <ralphschindler> bye guys :)
[20:49] <weierophinney> I'll try and get the summary posted later today; at latest, it'll be tomorrow mornign. :)
[20:49] <epoleacov> Bye, everyone.
[20:49] <prolic> ralphschindler, do you have a minute? i just wanted to ask what you think of my di extension I sent you