<ac:macro ac:name="toc" />
<li>Date: 25 April 2012, 20:00-21:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-04-25 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 02 May 2012</li>
<h3>ServiceManager Proposal (Was InstanceManager, Was ServiceLocator)</h3>
<p>(Entire log file below)</p>
<p>Ralph Schindler, after having created both the ServiceLocator proposal and working component (renamed to Zend\ServiceManager), is offering the Zend\ServiceManager prototype as well as a sample integration in the form of a ZendSkeleton application and Zend\Mvc refactoring up for inclusion in the framework.</p>
<p>Many quetions were asked about how ServiceManager and Zend\Di related to one another: Will SM replace DI, how will configuration work, how will we address the configuration structure issue. ralphschindler addressed each of these in the chat log below.</p>
<p>It was then suggested that the component and it's impact on Zend\Mvc be broken down into two phases, the first to get the ServiceManager into the framework as a component, then in a later phase, do the Zend\Mvc refactoring. This was put to a vote, and accepted:</p>
<blockquote><p>Do we accept the ServiceManager RFC?": 10 positives, 0 negatives and 2 neutrals, consensus: 10</p></blockquote>
<p><strong>tl;dr</strong>: Zend\ServiceManager tests and library code will be completed and a pull request will be issued.</p>
<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
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;
20:04:18 <weierophinney > Hey, folks, let's get started
20:04:31 < DASPRiD > !time
20:04:31 < Zend\Bot > 2012-04-25 20:04:37 UTC+0000
20:04:34 < DASPRiD > yup
20:04:34 < ocramius > indeed
20:04:35 <weierophinney > agenda is here: http://framework.zend.com/wiki/display/ZFDEV2/2012-04-25+Meeting+Agenda
20:04:52 <weierophinney > only one topic today: the ServiceManager RFC.
20:04:54 < SpiffyJr > Standup + ZF2 meeting at the same time. Phew.
20:04:59 <weierophinney > ralphschindler: YOU HAVE THE FLOOR
20:05:20 < DASPRiD > $channel->getFloor()->remove();
20:05:44 < SpiffyJr > $users->getUser('DASPRiD')->slap();
20:05:57 < DASPRiD > SpiffyJr, missing parameter $target
20:05:58 < DASPRiD >
20:06:02 <ralphschindle > ok
20:06:24 <ralphschindle > waiting for confluence
20:06:26 <ralphschindle > heh
20:06:58 < DASPRiD > i have no confidence in confluence
20:07:02 < ocramius > put more coal in it
20:07:11 < DASPRiD > throw more hardware at it
20:07:32 <ralphschindle > so the question that we are trying to answer is, has everyone had enough interaction with Zend\ServiceManager and read enough about it to decide how it moves forward
20:07:59 < DASPRiD > i briefly read your email
20:08:06 <ralphschindle > we've had numerous discussions about the various problems that are attempting to be solved
20:08:07 < DASPRiD > sounds good to me
20:08:26 <ralphschindle > one conclusion i have is that not everyone can be pleased by any solution
20:08:27 < ocramius > Nothing to say about ServiceManager itself, it looks good as it is
20:08:39 < DASPRiD > to me it basically sounds like an execution layer of a compilation part
20:08:58 <ralphschindle > there are two aspects to this: ServiceManager as a component, and ServiceManager's role in Zend\Mvc
20:09:29 < ocramius > same as I see it, but that's the use case, I'd discuss about educations of user after any eventual questions about implementation is done
20:10:24 <ralphschindle > does anyone have any questions about ServiceManager as a component?
20:10:29 < ocramius > ralphschindler: did we completely loose confluence?
20:10:35 <ralphschindle > ocramius: its there
20:10:35 < ocramius > ah, yes
20:10:40 < ocramius > one question
20:10:53 < ocramius > I didn't dig into it
20:10:57 < DASPRiD > (How about ServiceManager As A Service (SAAS))…
20:11:08 < ocramius > how is Di currently connected with ServiceManager?
20:11:27 < ocramius > missed that part, is that just a factory? If so, can Di reuse instances from ServiceManager?
20:11:46 <ralphschindle > Di can be consumed in a number of different ways by ServiceManager
20:12:01 <ralphschindle > as a service factory, as an abstract factory, or as an initializer
20:12:23 <WalterTamboer > ralphschindler: I don't like the idea of having it part of Zend\Mvc, it can be more useful as a component so one could use it without using Mvc.
20:12:23 <weierophinney > ocramius: in ralphs' branch right now, he registers it as an AbstractFactory – bascially, if the SM cannot create an instance, it would fall back to DI.
20:12:55 <weierophinney > WalterTamboer: it's not part of MVC, we're talking integrating with MVC
20:13:02 <WalterTamboer > ah right
20:13:10 < DASPRiD > weierophinney, sidenote: update topic
20:13:11 < ocramius > weierophinney: that is clear to me, but can Zend\Di\Di get back to the ServiceManager (checking $serviceManager->has('service') or $this->get('service')) ?
20:13:12 <weierophinney > WalterTamboer: as in, the base location implementation.
20:13:18 <weierophinney > ocramius: yes.
20:13:23 <WalterTamboer > weierophinney: got it
20:13:47 <weierophinney > ocramius: that's the other aspect of what ralphschindler did – he made a proxy, so you can have DI pull from the SM or from its definitions.
20:13:47 < ocramius > I missed THAT part from the discussion (Thought I've read it though today, but don't know where)
20:13:57 <weierophinney > ocramius: it's actually really, really slick.
20:14:20 <weierophinney > ocramius: you can also configure it so that it either prefers DI or the SM – basically, which to try first.
20:14:21 < ocramius > and that would allow getting dependencies from ServiceManager? Is that something like Zend\ServiceManager\Di ?
20:14:23 < DASPRiD > (darn, i read "sick"…)
20:14:33 <weierophinney > ocramius: yes.
20:14:49 * ocramius goes look. If it is exactly that, you are allowed to shoot me
20:15:01 <weierophinney > ocramius: https://github.com/ralphschindler/zf2/tree/feature/service-manager/library/Zend/ServiceManager/Di
20:15:08 < SpiffyJr > i managed to update to ralph's branch and my entire project worked as is using DI config
20:15:08 < ocramius > ok, shoot
20:15:12 * weierophinn shoots ocramius
20:15:19 <ralphschindle > when it comes down to it, i think that it can be explained as ServiceManager, along with EventManager is a dependency of Zend\Mvc
20:15:19 < SpiffyJr > which was very nice
20:15:22 * weierophinn needs Tazer-over-IP protocol
20:15:31 < ocramius > weierophinney: so here's a question
20:15:46 < ocramius > is the ServiceManager depending on Zend\Di or is Zend\Di depending on ServiceManager?
20:16:01 <ralphschindle > ServiceManager optionally consumers Di
20:16:09 <ralphschindle > consumes*
20:16:19 < SpiffyJr > neither, i think
20:16:26 <ralphschindle > only if you register one of those above linked factories as a service
20:16:27 < SpiffyJr > yea, what he said!
20:16:35 < ocramius > SpiffyJr: it is just because there's usage of Di inside ServiceManager ns
20:16:53 < ocramius > ok, that is almost all of it from me then
20:16:56 < DASPRiD > weierophinney, https://twitter.com/#!/gattaca/status/186915498460590080
20:17:01 < DASPRiD > weierophinney, you are 23 days late
20:17:31 <ralphschindle > the DiServiceFactory et al. are implementations of a factory that can be used in situations where you want to use Di as a factory for a particular service
20:18:41 < ocramius > yep, it looks really good and slick, as matt said
20:18:58 <weierophinney > In my talks with ralphschindler, the thing to think about here is that we're currently stuffing a lot of stuff in DI that we really don't care about. A lot of dependencies are simply that, dependencies; we have no interest in pulling them ever, except to fulfill dependencies of other services.
20:19:31 <weierophinney > If we can simplify that story, and make starting with the framework easier, I think we have a win.
20:20:00 <weierophinney > ocramius: the other thing: a lot of the MVC integration ralphschindler did makes sense from a "these are the defaults; they should be readily and quickly available" standpoint.
20:20:19 <weierophinney > but some of that could be relegated to DI as well. We need to strike a balance.
20:20:19 < ocramius > ya
20:20:24 < Akrabat > Do we have a story around configuration yet?
20:20:35 <ralphschindle > Akrabat: what do you mean?
20:20:38 <weierophinney > Akrabat: no. I think we need to work on that.
20:20:56 < DASPRiD > can matthew read minds? i didnt understand the Q either
20:20:56 <weierophinney > ralphschindler: well, the argument from the DIC camp is that the configuration is at least following a regimented structure.
20:20:58 < Gabriel403 > Could someone explain simply what the servicemanager gives me, as a relative noob, compared to not having it?
20:21:03 < DASPRiD > ah
20:21:18 < ocramius > weierophinney: so here's an insane idea. If I wanted to have an instance defined in Di again, would I just replace the factory for it with a dummy factory using the Di abstract one?
20:21:20 < Akrabat > ralphschindler: currently $config['di'] conflates configuration with dependency definition
20:21:22 <weierophinney > ralphschindler: with the SM, configuration becomes more arbitrary in structure.
20:21:30 < SpiffyJr > Gabriel403, a way to configure, store, and retrieve services.
20:21:31 <ralphschindle > Gabriel403: gives you all the structure of Di without auto-wiring and auto-initialization
20:21:32 <weierophinney > ocramius: probably.
20:21:42 < ocramius > Gabriel403: ServiceManager is a mix of instantiation (via factories) and registry
20:21:54 < DASPRiD > registry…
20:21:57 <weierophinney > Gabriel403: think of it this way: code-driven DI, vs. configuration driven DI.
20:22:00 < ocramius > Gabriel403: it handles what Zend\Di did before, but it without any magic
20:22:05 * DASPRiD enables TOIP on his end
20:22:09 < ocramius > Gabriel403: all the logic goes to these "factories"
20:22:25 < Gabriel403 > OK
20:22:31 < Gabriel403 > Thanks
20:22:37 <weierophinney > Gabriel403: basically, explicit wiring, vs. implicit.
20:22:50 * ocramius awaits DASPRiD's comment
20:22:50 < ocramius >
20:22:55 <ralphschindle > so, with regards to configuration, i am not sure i buy the structure of configuration argument
20:22:58 < Akrabat > I'm generally in favour of SM as long as we have a predictable convention for config
20:23:16 <ralphschindle > configuration with DI is largely dictated by the name of a parameter in a method somewhere
20:23:29 <ralphschindle > which is just as arbitrary as the name of a config value on some page in a manual somewhere
20:23:31 < mwillbanks > i have a question for those of us with some existing applications; what does the conversion process look like or can we just tell SM to take our DI config?
20:23:34 * mwillbanks hides
20:23:36 < DASPRiD > ocramius, about what?
20:23:49 < ocramius > mwillbanks: you can still use Di config
20:23:54 <ralphschindle > mwillbanks: largely, it still works as is
20:23:56 < DASPRiD > mwillbanks, Di will have a code generator
20:24:02 < mwillbanks > DASPRiD: woot!
20:24:05 <weierophinney > mwillbanks: you can just have it use DI – that's the fallback. SpiffyJr talked about that earlier.
20:24:07 * EvanDotPro enters a bit late.. catching up now.
20:24:07 < ocramius > mwillbanks: just some of the services will be driven by SM, thus Di will have no effect on them
20:24:07 < DASPRiD > mwillbanks, at least that's what ralphschindler's mail says
20:24:17 <weierophinney > mwillbanks: and then gradually move to services as needed.
20:24:32 * mwillbanks would be very happy for a generator to fix performance lol
20:24:41 < Akrabat > ralphschindler: with config['di'], it's easy to find the correct config - you just read the class's API docs page which is auto generated and hence not out of date
20:24:42 < SpiffyJr > mwillbanks, all i did was merge ralph's branch, make the index.php/config updates
20:24:47 < SpiffyJr > and it worked with all other di config
20:24:54 < mwillbanks > nice; all good then
20:25:07 <weierophinney > Akrabat: I would argue having a key named after the factory or service name, and then keys beneath for the configuration parameters.
20:25:09 < Akrabat > ralphschindler: SM will require reading code
20:25:20 <ralphschindle > Akrabat: or a manual page
20:25:22 < ocramius > weierophinney: that needs some good conventions
20:25:29 <ralphschindle > which is the same as you reading an API page
20:25:32 < Akrabat > ralphschindler: assuming manual page is up to date
20:25:38 < Akrabat > API page is auto-generated
20:25:39 <weierophinney > ocramius: definitely.
20:25:42 < ocramius > I liked Di especially for it's strict relation with class signature
20:25:43 <weierophinney > Akrabat: yes.
20:26:00 < Akrabat > i.e I do not trust the ZF1 reference manual for config keys...
20:26:10 <weierophinney > ocramius: the problem, though, is that it also forces case sensitivity on configuration, which is a problem.
20:26:24 <ralphschindle > Di is great for people who write SOLID OO code, but the 30 people in this room don't represent the 3000+ ZF developers out there that dont
20:26:34 <weierophinney > Akrabat: what about having config keys in the API docs for the factories?
20:26:45 < Akrabat > weierophinney: that's definitely the way forward
20:26:47 < ocramius > weierophinney: not sure it is a problem, as keys could contain any utf-8 stuff if I wrote my classes in tr_TR
20:26:50 < DASPRiD > ralphschindler, i thought we where in here because we do
20:27:10 < DASPRiD > ocramius, i hope you dont
20:27:20 < ocramius > DASPRiD: I'm stupid, but not that much
20:27:24 <weierophinney > ocramius: case senstivitity in keys has been a huge problem in ZF1. Ask Akrabat or Bittarman.
20:27:25 < DASPRiD >
20:27:38 < ocramius > I'll set it as a fact then
20:27:41 < Akrabat > ralphschindler: I'm still not sure I really understand what SOLID is, so I'm sure I don't write it Which is of course, one reason why I struggle whent my DI goes "wrong"
20:27:43 < DASPRiD > ocramius, actually, we have no cs convention which states that you have to write zf code in english…
20:27:55 < epokmedi1 > Question : How the ServiceManager will help in some generic initialization like setting the basepath on the basePath view helper ?
20:28:14 < Akrabat > ocramius: yes - take it as read that config keys needs to be lowercase, underscore separated
20:28:19 < ocramius > so here's my (small) proposal
20:28:24 <ralphschindle > Akrabat: in short, dont use statics, inject your dependencies all the time, use interfaces appropriately and make sure youre objects dont to get too big with too many responsibilities
20:28:38 <weierophinney > epokmedi1: one possibility is you create a "View" factory for your application. In there, you grab the configuration, and use it to seed helpers in addition to instantiating your view.
20:28:48 < Akrabat > ralphschindler: I'm probably "SOLID-ish" then
20:28:50 < ocramius > start separating docs/tutorials for consumers (people that USE the zend skeleton application) and for people who write modules
20:28:55 < ocramius > (reusable)
20:29:01 <weierophinney > epokmedi1: in other words, we can move some of the boilerplate that we have in the application Module into a service factory instead.
20:29:05 < ocramius > that would keep the entire Di stuff hidden
20:29:13 < Akrabat > ocramius: everyone will write modules
20:29:17 < epokmedi1 > weierophinney: okay that's the answer i needed
20:29:18 * EvanDotPro is caught up
20:29:26 < Akrabat > you can't do anything in ZF2 without knowing DI atm
20:29:26 < ocramius > while still allowing awesomeness for the ones who wants to write awesome stuff
20:29:34 < ocramius > Akrabat: yes, I know that
20:29:43 <weierophinney > ocramius: I agree with that approach.
20:29:47 < ocramius > Akrabat: but we could simplify the docs
20:29:52 < EvanDotPro > personally, i think if we support both strategies, there's not much of a problem.
20:29:53 < ocramius > assuming people just know about the IM
20:29:57 < ocramius > (SM)
20:30:00 < ocramius > not about Di
20:30:07 < Akrabat > however, I don't disagree with improvind the docs and targetting them
20:30:13 < ocramius > so $locator->get('stuff')
20:30:16 < ocramius > which is both simpler
20:30:26 < ocramius > but which I fear because of what Symfony 2 became
20:30:27 < SpiffyJr > servicemanager->get()
20:30:36 < ocramius > SpiffyJr: yeah
20:30:54 < SpiffyJr > mwillbanks, that reminds me - if you use getLocator() it needs to be changed to getSErviceManager() on ralph's branch
20:31:03 < ocramius > I just have fear of people starting spreading ids everywhere
20:31:13 < ocramius > that's my main point about all this stuff
20:31:17 < Akrabat > what's an id?
20:31:17 <ralphschindle > which is fine
20:31:23 <ralphschindle > b/c you can alias someone elses service
20:31:28 < SpiffyJr > ocramius, take, for example, doctrine_em
20:31:38 < SpiffyJr > ocramius, you keep wanting to swap to Doctrine\ORM\EntityManager but what if a single project has multiple instances?
20:31:40 <weierophinney > ocramius, Akrabat: I'd argue we still recommend using FQCN for identifiers for the most part.
20:31:40 <ralphschindle > EvanDotPro's user module will call zfuser_adapter
20:31:42 < ocramius > SpiffyJr: yeah, I'm gonna strip it with 0.2
20:31:44 < SpiffyJr > i prefer aliases
20:31:48 < EvanDotPro > Akrabat: i agree that DI config relates to class signatures who's documentation is kept up to date with api docs – that's great for those of us who like that, understand DI, appreciate how crappy config keys in user docs are, etc.. but that's also part of the complexity a lot of are complaining about right now... having to go and look at the signatures, wire up the classes, deal with huge config files... then again, you k
20:31:55 <ralphschindle > which can be configured to alias whatever the actual service is called
20:32:05 < ocramius > SpiffyJr: multiple instances = multiple ids, but that should not come with the module itself
20:32:12 < ocramius > module should also show the sane default
20:32:21 < SpiffyJr > fair enough
20:32:30 < ocramius > the right way, especially when a module such as ORM module will be used MORE than we think
20:32:49 < ocramius > Akrabat: Symfony has "ids" for services
20:32:50 < Akrabat > EvanDotPro: yeah - I was just explaining how DI is, by definition, structured config. Complicated, but structured (if you know the rules)
20:33:06 < ocramius > you do $locator->get('some.id.you.must.remember') all over the place
20:33:15 <ralphschindle > ocramius: no
20:33:16 <ralphschindle > hyou dont
20:33:19 < ocramius > that makes everything locator dependent :\
20:33:22 <ralphschindle > your code uses the names you setup
20:33:26 <ralphschindle > this is the point of aliasing
20:33:29 < EvanDotPro > Akrabat: yep, i agree. and i appreciate it for that... too bad the general population doesn't as well, heh.
20:33:36 < ocramius > ralphschindler: yes, what I mean is that bundle devs did
20:33:43 < ocramius > ralphschindler: and now you can only use these ids
20:33:44 < Akrabat > weierophinney: yes fqcn appeals as it becomes self-documenting
20:33:45 <ralphschindle > yes, its the better architecture
20:33:50 < ocramius > that is because the thing got out of control imo
20:33:51 <ralphschindle > NO
20:33:59 <ralphschindle > you're missing the point
20:34:12 <weierophinney > ralphschindler: what was the "no" directed at?
20:34:13 <ralphschindle > you call your services, both provided and consumed by whatever name you decide
20:34:35 < ocramius > yes, that's fine
20:34:36 <ralphschindle > the merged configuration will have the proper 'youalias' => 'actual.service.name'
20:34:47 < DASPRiD > ocramius, number of the service: 555 346352, go call it
20:34:52 <weierophinney > ocramius: I feel strongly that locator usage (whether DI or SM) should be mainly at the gateway level of the request – objects in the execution cycle should largely be unaware of its existence.
20:35:06 < ocramius > weierophinney: nailed it
20:35:17 < ocramius > ralphschindler: yes, you can alias the alias, that's fine
20:35:45 < ocramius > ralphschindler: but still, sf has become messy because everything uses locators with no rule or no direction
20:35:58 < ocramius > that is what we need before getting on with ServiceManager
20:36:02 < mabe_ > 000000000000000000000000000000
20:36:03 < ocramius > prevent that
20:36:17 <ralphschindle > you can't prevent that
20:36:26 <ralphschindle > having that is the reason module/plugin ecosystems flourish
20:36:28 <ralphschindle > look at wordpress
20:36:32 <ralphschindle > some of the worst code you can find
20:36:33 < ocramius > you can't, of course, but you can give right directions
20:36:39 <ralphschindle > but theres 10000's of plugins
20:36:42 < ocramius > yes, I know that
20:36:47 < mabe_ > oh sorry - my cat talked with you
20:36:49 < Akrabat > At the end of the day, all I want to do is have an easy way to set up my database (or smtp) credentials and get at them in the db adapter that's within my mapper that's composed by my service object when I create that service object in my controller...
20:36:55 < ocramius > mabe_: hi cat!
20:36:57 < DASPRiD > mabe_, lol
20:37:01 < DASPRiD > mabe_, pic or it didnt happen
20:37:02 < Akrabat > I'd quite like it to not take a nested array that's 10 levels deep...
20:37:09 <weierophinney > mabe_: LOL
20:37:19 < ocramius > ralphschindler: we can give sane directions
20:37:21 < ocramius > OR
20:37:35 < ocramius > like EvanDotPro did with matus, stop him before it's too late
20:37:47 <weierophinney > Akrabat: I think the SM will make that story much, much better. We'll need to play with how to make configuration discoverable, but I think we can make it much flatter.
20:37:49 <ralphschindle > i'd opt for creating an infrastructure that allows discrepancies to be resolved
20:37:50 < ocramius > but I guess sane directions is better instead of having the last 2 hours of sleep stolen from EvanDotPro
20:38:00 <ralphschindle > what is matus?
20:38:05 < ocramius > matuszemi
20:38:15 < EvanDotPro > lol ocramius
20:38:15 <ralphschindle > and who's going to stop a developer that is not in the zf2talk channel?
20:38:18 <weierophinney > ocramius: if we steal 2h of sleep from EvanDotPro, he doesn't sleep for 28h.
20:38:31 < ocramius > weierophinney
20:38:35 < DASPRiD > ralphschindler, the community police team
20:38:44 <weierophinney > kk, I'm going to step in...
20:38:56 < ocramius > ralphschindler: yes, exactly, you can't, but some directions help
20:39:02 <weierophinney > It sounds like general consensus is, "let's give it a shot and iron out the details as we go"
20:39:13 <weierophinney > Should I start a vote on the ServiceManager?
20:39:17 < DASPRiD > sounds like a plan
20:39:25 < ocramius > ServiceManager is already as good as merged for me
20:39:35 < ocramius > it is GOOD
20:39:36 <weierophinney > !start-vote Do we accept the ServiceManager RFC?
20:39:37 < Zend\Bot > Vote "Do we accept the ServiceManager RFC?"; type either +1, -1 or 0
20:39:38 <ralphschindle > well, it needs cleanup in the tests department
20:39:41 <weierophinney > +1
20:39:42 < EvanDotPro > +1
20:39:43 < ocramius > +1
20:39:44 < Akrabat > I want the details iron out before b4 is released
20:39:44 <ralphschindle > +1
20:39:45 < Akrabat > +1
20:39:50 < mabe_ > +1
20:39:50 <weierophinney > Akrabat: agreed.
20:39:58 < SpiffyJr > +1
20:40:00 < Thinkscape > +0.3
20:40:08 < DASPRiD > +1
20:40:09 <weierophinney > Gabriel403?
20:40:17 < Akrabat > hey! it's Thinkscape! Good to see you, sir
20:40:19 <weierophinney > OMG – Thinkscape – you're HERE?????
20:40:19 < mabe_ > Thinkscape: lol
20:40:21 < ocramius > Thinkscape: Y U CRASH DASPRiD's bot?
20:40:22 < EvanDotPro > and suddenly Thinkscape comes out of NOWHERE!
20:40:27 < epokmedi1 > +1
20:40:27 < Thinkscape >
20:40:29 < Gabriel403 > 0
20:40:31 < DASPRiD > Thinkscape, HEY
20:40:36 < epokmedi1 > yay
20:40:37 < epokmedi1 > +10000
20:40:42 <weierophinney > mwillbanks: ?
20:40:49 < Thinkscape > btw: with config merging you won't realistically see 10-level deep arrays. Just a bunch of files that are merged into 10-level deep arrays.
20:40:50 <weierophinney > SocalNick: ?
20:40:51 < mwillbanks > +1
20:40:53 < mwillbanks > sorry
20:40:54 < Thinkscape > But files contain simple arrays.
20:40:57 <WalterTamboer > +1
20:40:59 < SocalNick > 0
20:41:09 <weierophinney > Bittarman: ?
20:41:12 <weierophinney > Freeaqingme: ?
20:41:17 <weierophinney > MikeA_: ?
20:41:22 <weierophinney > wilmoore: ?
20:41:28 <ralphschindle > Thinkscape: with merged arrays, the deepest level is still the same
20:41:35 * weierophinn is thinking some folks are just camped out i nthis channel...
20:41:35 < Thinkscape > +1E-10
20:41:45 < Akrabat > Thinkscape: yeah - 5 deeps is usual
20:41:46 < Thinkscape > ralphschindler: you're not seeing it.
20:41:49 < SocalNick > i'm really digging Di so far, but can see the possible performance gains from SM, so I'm a 0
20:42:00 < DASPRiD > Thinkscape, status on zend\console?
20:42:01 < Thinkscape > ralphschindler: my point being - we can engineer it to be more user-friendly.
20:42:05 * wilmoore was camping
20:42:07 < Thinkscape > DASPRiD: stalled.
20:42:21 < DASPRiD > Thinkscape, bad!
20:42:27 < EvanDotPro > SocalNick: performance is really my main argument for it as well – we simply can't compete with the current DI performance for high traffic ises.
20:42:28 < Thinkscape > DASPRiD: absolutely 0 feedback. And no interest from other contributors - see what Victor said.
20:42:28 <weierophinney > DASPRiD: it appears Thinkscape is stalled waiting for feedback from me.
20:42:35 < EvanDotPro > s/ises/sites
20:42:39 * wilmoore has only complaints right now...will discuss offline.
20:42:43 <weierophinney > !end-vote
20:42:43 < Zend\Bot > Vote result for "Do we accept the ServiceManager RFC?": 10 positives, 0 negatives and 2 neutrals, consensus: 10
20:42:44 < Thinkscape > weierophinney: that is the second reason [pun]
20:43:01 <weierophinney > wilmoore: kk – ping us in #zftalk.2 afterwards.
20:43:01 < EvanDotPro > i have a high traffic ringtone site that i really can't refactor until performance is better because DI will just crush my server with the traffic i have.
20:43:13 <ralphschindle > ok, so I will get the component ready with tests, docs
20:43:13 < wilmoore > weierophinney: will do
20:43:22 < Thinkscape > ralphschindler: we can also use something that is reverse to factory -> DI . For example something -> DI def.
20:43:42 * ocramius really has to play around with some code generation :\
20:43:44 <ralphschindle > Thinkscape: i dont follow
20:43:56 <weierophinney > Thinkscape: I'll try and get the feedback you need this week. Been crazy this week with meetings.
20:44:34 <weierophinney > ocramius: that would be awesome. Maybe work with Thinkscape to create a console tool for it?
20:45:08 < ocramius > weierophinney: I don't know if I can integrate in console, but I'll buy some chains and stay the weekend at my pc playing around with it
20:45:19 < ocramius > I want a POC, even if dirty as hell (I am a crappy coder)
20:45:34 < ocramius > still believe strongly in Di, as said
20:45:36 < epokmedi1 > Thinkscape: in fact i was looking for you like for 2 weeks on the zf chan to see if you needed help on your zend\console component
20:46:09 < DASPRiD > everyone was looking for him
20:46:12 < epokmedi1 > we are going to need this kind of component more than anything and i'd like to help you
20:46:14 < MikeA_ > weierophinney: was scrolling
20:46:17 < MikeA_ > 0
20:46:18 <weierophinney > ocramius: remember, it's two-pronged – not just generation, but consuming the generated definitions – which means being able to provide a list of definitions to use.
20:46:48 < ocramius > weierophinney: my point is generating a closure for EVERY config.di.instance.alias
20:46:58 < ocramius > and every config.di.instance
20:47:15 <weierophinney > ocramius: right... and that's going to be... interesting.
20:47:24 < ocramius > then put a compiledDiFactory in front of the di factory in SM
20:47:58 < ocramius > weierophinney: indeed, I already see my panic this weekend, but it needs some experimenting
20:48:03 <ralphschindle > actually, you could simply compile the aliases into service factories and register them with SM
20:48:07 <ralphschindle > that was my goal
20:48:30 < ocramius > ralphschindler: that is impl. detail for now I need to generate the closures or whatever it is
20:48:35 <weierophinney > ocramius: also, keep in touch with ralphschindler – he's creating an AMI we can use for benchmarking.
20:48:41 <ralphschindle > closure or FactoryInterface, same thing
20:48:45 < ocramius > yep
20:48:48 < ocramius > ralphschindler yup
20:48:51 <ralphschindle > in fact, let me go do that now
20:49:05 < ocramius > yeah, I guess the area is cleared
20:49:10 <weierophinney > kk, folks, let's call it a day.