10:47 <@Crell> OK, I think we're ready to get started.
10:47 < tsvenson> hejrocker: Don't they have real whiskey there? :)
10:48 <@Crell> Thank you everyone who is here!
10:48 <@Crell> Roll call!
10:48 -!- Janusman [~janusman@drupal.org/user/153120/view] has joined #drupal-wscci
10:48 -!- darthsteven [~darthstev@109.123.86.70] has joined #drupal-wscci
10:48 -!- travelertt [~travelert@208.176.184.35.ptr.us.xo.net] has joined #drupal-wscci
10:48 < neclimdul> Crell: its too early. you should kill 30sec reading this: http://i2.kym-cdn.com/photos/images/masonry/000/173/910/0c595a5b-270f-4455-b0ad-519.jpg
10:49 <@Crell> boux!
10:49 < EclipseGc> booo...
10:49 < EclipseGc> btw, "here"
10:50 < Janusman> neclimdul: :D
10:50 <@Crell> Is anyone here except EclipseGc? :-)
10:50  * EclipseGc is happy to monopolize if need be
10:50 < Janusman> lurkers gonna lurk
10:50 < Michelle> Here but lurking... I doubt I'll have anything useful to contribute so just want to read and try to learn.
10:50 < neclimdul> obviously i'm not
10:50 <@Crell> cboden: You still around?
10:50 -!- tsvenson is now known as tsvenson|lurking
10:50 < hejrocker> i am here but leaving in ten minutes to go through security
10:50 < cboden> Crell: I'm here
10:50 <@Crell> Enjoy your anal probe.
10:50 < EclipseGc> security boo
10:50 -!- ksenzee [~ksenzee@drupal.org/user/139855/view] has joined #drupal-wscci
10:51 <@Crell> OK then...
10:51 < EclipseGc> Crell: he's not in America yet, so hopefully not
10:51 < hejrocker> No im in sweden
10:51 < davereid> http://youtu.be/nOBlXZyKC6A?t=1m2s
10:51 < davereid> roll call!
10:51 < hejrocker> ROBOT ROLL CALL
10:51 < EclipseGc> dependency injection
10:51 < dixon_> I'm here as well, listening in while rolling a couple of module releases at the same time...
10:52 <@Crell> So, there hasn't been a huge amount happening since last meeting. :-)
10:52 <@Crell> EclipseGc is still working on plugins.
10:52 -!- fabpot [~fabpot@symfony/developer/fabpot] has joined #drupal-wscci
10:52 <@Crell> And I am working on actually using the Symfony2 request object in core: http://drupal.org/node/1417320
10:52 < EclipseGc> wow, fabpot in here
10:52 <@Crell> That's blocked on our testbot being weird.
10:52 <@Crell> Hi, fabpot! :-)
10:52 < fabpot> Hi all
10:53 <@Crell> I see someone follows my tweets... ;-)
10:53 < EclipseGc> fabpot: you made it to our bi-weekly meeting :-)
10:53 < fabpot> I know
10:53 <@Crell> fabpot: I want to talk to you about Denver too, after this meeting.
10:53 <@Crell> Anyway...
10:53 < fabpot> I like meetings about Dependency Injection ;)
10:53 <@Crell> hehe.
10:53 -!- batsonjay [6b00ff81@gateway/web/freenode/ip.107.0.255.129] has joined #drupal-wscci
10:53 <@Crell> What I want to talk about today is dependency injection, specifically how we want to do it.
10:53 -!- Stalski [~stalski@dD5768671.access.telenet.be] has joined #drupal-wscci
10:54 <@Crell> Basic idea: all of our various systemy-type-things need their hard dependencies eliminated.  That's just good practice.
10:54 <@Crell> That means 1) Make 'em objects;  2) Pass other systemy-type objects to them (database connecctions, caches, session handling, password hasher, etc.)
10:54 <@Crell> There are lots of ways to do the latter.
10:55 <@Crell> I want to try and figure out which way we want to go with it.
10:55 -!- hejrocker [~heyrocker@109.58.147.4.mobile.3.dk] has quit [Quit: Leaving]
10:55 <@Crell> Generally speaking:
10:55  * EclipseGc has started this on his own time right now as well
10:56 <@Crell> 1) Pimple-style.  Basically we have a big-ass array-like object, which spawns objects for us.  We pass that one object to everything, and then objects call against it.
10:56 < EclipseGc> for reference: http://pastebin.com/YXAzgtvG
10:56 <@Crell> Example: $this->services['cache.filter']->get($cache_key);
10:56 < EclipseGc> the config stuff all needs converting to something sane still
10:56 <@Crell> Pros: Quite easy to implement.
10:56 -!- indytechcook is now known as indy-brb
10:56 -!- batsonjay is now known as jayb
10:57 -!- jayb is now known as jay-batson
10:57 <@Crell> Cons: Not all that configurable, needs to be re-initialized every page request, and somewhat obfuscated call chains.
10:57 <@Crell> 2) Syfmony2-style.  Basically you setup macros to call methods on an object when it's lazy-created.
10:57 < fabpot> if you pass the container to all object, this is not dependency injection anymore, but a service locator
10:57 <@Crell> Example: http://fabien.potencier.org/article/62/create-your-own-framework-on-top-of-the-symfony2-components-part-12
10:58 <@Crell> fabpot: True. :-)
10:58 -!- nikkubhai [ca4eafc7@gateway/web/freenode/ip.202.78.175.199] has joined #drupal-wscci
10:58 <@Crell> Pros: The objects that get instantiated get a simpler syntax when using.
10:58 < fabpot> which is not a bad thing in itself, it just introduces a central object
10:58 <@Crell> It's also possible to serialize, although I don't know if we can given that we cannot write PHP code from the web GUI securely.
10:58  * EclipseGc needs a central object if we're going to run the plugin system through this
10:59 < fabpot> also, as far as unit testing is concerned, true dependency injection is better. When using a service locator, you need to create a specific one for your tests
10:59 <@Crell> EclipseGc: Not necessarily. ;-)
10:59 -!- xjm [~xjm@drupal.org/user/65776/view] has joined #drupal-wscci
10:59 <@Crell> Cons: More complex setup.  Especially given our volume, it may be a nightmare to manage without the compiled step.
10:59 < fabpot> EclipseGc: the idea behind a container is pass it as less as possible (but in some cases, it might make sense)
11:00 < EclipseGc> fabpot: yeah, super new to a lot of this stuff, I'm mostly trying to play in order to understand wtf is going on :-)
11:00 <@Crell> One thing that I firmly believe is that we need to allow an class to define what its dependencies are, not an interface.  That is, different plugins of the same type may have different dependencies.
11:00 <@Crell> EclipseGc: That's true for most of Drupal, methinks. ;-)
11:00 <@Crell> So what I'd like to do today is two fold
11:01 <@Crell> 1) Discuss those two basic approaches and get a better grasp on direction if we can.
11:01 < EclipseGc> Crell: but those dependencies would be defined by implementing various interfaces
11:01 <@Crell> 2) Work up some API/DX user stories to help us work out what the API should look like, and if we can just use Pimple or SF2 as is or should roll our own inspired by one of those.
11:01 <@Crell> Right now I consider those all on the table.
11:01 -!- batsonjay [~batsonjay@mobile-198-228-193-035.mycingular.net] has joined #drupal-wscci
11:01 <@Crell> EclipseGc: Potentially.  That's one way we could do it, but not the only.
11:01 <@Crell> So, I'm done talking for a bit. :-)
11:01 < EclipseGc> hmm ok
11:02 <@Crell> Anyone want to weigh in?  Questions?  Comments?  Additional pros/cons?
11:02  * Crell should really have prepared his speech in advance...
11:02 < Stalski> Crell: sounds great. but one question
11:02 < EclipseGc> well, I'm enjoying the pimple approach from the url I pasted above
11:02 < pounard> hello
11:02 < Druplicon> hey
11:02 < EclipseGc> I see a lot of benefit to moving much of the bootstrap there, and would love to see someone actually dive into that idea
11:03 < Stalski> It get the impression while reading that you are not in favor of the pimple style? or is my impression wrong ;)
11:03 < neclimdul> EclipseGc: service locator isn't mutually exclusive to di so plugins may very well use both
11:03 <@Crell> Pimple-style, a Service Locator, is what I'd originally been thinking of.
11:03 < EclipseGc> neclimdul: yeah, but I put the plugin mapper as a closer in the kernel, so...
11:03 < EclipseGc> closure*
11:03 < Stalski> Crell: well, then it seems less attractive to have a big ass object passed on to ever
11:03 < Stalski> ything
11:04 -!- indy-brb is now known as indytechcook
11:04 < EclipseGc> neclimdul: line 19 http://pastebin.com/YXAzgtvG
11:04 -!- kylebrowning_ [~kylebrown@c-67-160-239-22.hsd1.ca.comcast.net] has joined #drupal-wscci
11:04 <@Crell> However, that has downsides: Single-point-of-failure, we have to pass that object to frickin' everything, and it may be difficult to reinitialize on every request in a performant way.
11:04 < neclimdul> EclipseGc: I'm not sure what that means but I'm certain plugins is sort of its own discussion seperate from this
11:04 <@Crell> Well, by "big ass" I don't necessarily mean memory-bloated.  Pimple itself is quite efficient.  It's basically the same model as the Context API patch we did.
11:04 < Stalski> that's certainly a remark that has to be taken into consideration
11:04 < pounard> EclipseGc> use Drupal\Core\Plugin\Mapper as PluginMapper
11:04 -!- samkottler1 [~Adium@155.47.176.79] has joined #drupal-wscci
11:04 < fabpot> I don't know Drupal that well, and I don't know what you are going to use the container for, but I have the feeling that the Symfony2 container would be more appropriate for you
11:05 < Stalski> performance
11:05 <@Crell> Stalski: Yes.
11:05 <@Crell> fabpot: Why is that?
11:05 < fabpot> especially because the Symfony2 container is able to optimize and dump your container as a PHP class
11:05 <@Crell> fabpot: Right, that's the part that I don't know we could leverage, since that requires a CLI to update.
11:05 < EclipseGc> pounard: yeah I'm not passing this around so that section's not actually usable yet, but yes.
11:05 < fabpot> also because we have compiler passes that allows you to manage plugins configuration quite easily
11:05 <@Crell> And we cannot require use of a CLI to make config changes, due to our usage models.
11:05 -!- halcyonCorsair [~quassel@2404:130:0:1000:e269:95ff:fe3c:c570] has joined #drupal-wscci
11:06 < fabpot> Crell: ah, ok, I didn't know that
11:06 < pounard> I'm not sure the compiler passes would help us, I say that at first sight
11:06 <@Crell> Yeah, it's a symptom of the CMS side of Drupal rather than the framework side.
11:06 -!- darthsteven [~darthstev@109.123.86.70] has left #drupal-wscci ["Ex-Chat"]
11:06 < dixon_> fabpot: but can't you configure the container in other ways than dumping it into PHP?
11:06 <@Crell> Now, if there were a way to serialize DI configuration that didn't require writing to PHP code, then that would be interesting.
11:06 < samkottler1> hey jay-batson!
11:06 < fabpot> but there is no need for a CLI as the container can be dumped when the very first request comes in, no?
11:06 < batsonjay> Hi, Sam.
11:06 < pounard> the Zend Di component is more like we may need
11:07 < pounard> just sayin'
11:07 -!- jstanton617 [~jim@bherald-srx220.cust.e-xpedient.com] has joined #drupal-wscci
11:07  * Crell has not seen the Zend DI.
11:07 < fabpot> and anyway, dumping to PHP is entirely optional
11:07 <@Crell> fabpot: No, the problem is writing PHP code from an apache web process.
11:07 <@Crell> That's a security hole.
11:07 <@Crell> Our security team would have a fit if we tried it. :-)
11:07 < Stalski> indeed
11:07  * batsonjay wishes he was _really_ a PHP dev (instead of Just a C/C++ dev)…  He'd sound less foolish when he says "Why pass an array, when you can pass a pointer instead." :-)
11:07 < EclipseGc> and really, the last people we need mad at us is the security team
11:08 < pounard> we could generate code at install, but this would change the install environment  requirements
11:08 < fabpot> you can also let people with access to a CLI benefit from a dumped container and let others use the non-compiled version
11:08 < pounard> and a lot of people would be unhappy
11:08 <@Crell> fabpot: True.  However, and this is a problem with both an SL and SF2 DI, we still then need to invoke a hook in all modules to wire up configured objects.
11:08 <@Crell> That's an unpleasant performance hit, especially given the dependencies needed for locating modules to invoke.
11:08 < Stalski> fabpot: that sound acceptable somehow
11:09  * Crell is open to considering that if there's no alternative, but we'd have to run it past Dries and catch.
11:09 -!- exlin [~eXlin@77.86.211.112] has joined #drupal-wscci
11:09 < EclipseGc> Crell: I'm sort of wondering if we can't short cut module bootstrap to some extent by leveraging CMI to write to file everything we might need to know about modules… like dir etc
11:09 < batsonjay> @fabpot - wouldn't you need to re-dump the container every time you made a change in config? I can see this as being a support nightmare...
11:09 <@Crell> EclipseGc: That is a maybe.  But, that still means we're writing code that affects execution, no?
11:10 <@Crell> Too bad hejrocker had to leave.
11:10 < pounard> Drupal is too dynamic now for the compiler model
11:10 < fabpot> batsonjay: not necessarily (depends on what you have changed in your configuration and what optimizations you have enabled)
11:10 < fabpot> pounard: ok, then don't use the compilation part
11:10 < EclipseGc> Crell: I'm just thinking a little json/xml file somewhere that would substitute for having to bootstrap all modules before we can get at classes etc within them
11:10 <@Crell> fabpot: How flexible is the exporter?  Could we dump to, say, a custom JSON format instead of PHP?
11:10 <@Crell> We MAY be able to get away with that.
11:10 < fabpot> Crell: sure. Right now, we support dumping into PHP, YAML, XML… we can probably add JSON too if needed
11:11 <@Crell> EclipseGc: We may need to do that for the class loader, too.
11:11 < pounard> Crell> you mean reading configuration to export configuration? What's the benefit of it?
11:11 < EclipseGc> Crell: that's what made me actually consider it
11:11 -!- fago [~fago@chello084112011033.13.11.vie.surfer.at] has quit [Ping timeout: 276 seconds]
11:11 < pounard> or did I miss something about the compiler/exporter?
11:11 < fabpot> pounard: I think he means reading configuration to create the container that is then optimized and dump as JSON
11:11 <@Crell> pounard: We want to be able to say "the cache class being used for the page class is in the memcache module", without first having to bootstrap the database and module system, both of which use, uh oh, the cache. :-)
11:11 <@Crell> What fabpot said.
11:12 -!- stevector [persch@gateway/palantir/session] has quit [Ping timeout: 244 seconds]
11:12 -!- samkottler [~Adium@155.47.176.79] has quit [Ping timeout: 244 seconds]
11:12 -!- kylebrowning [~kylebrown@c-67-160-239-22.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
11:12 -!- corsair__ [quassel@leibniz.catalyst.net.nz] has quit [Ping timeout: 240 seconds]
11:12 -!- nikkubhai [ca4eafc7@gateway/web/freenode/ip.202.78.175.199] has quit [Ping timeout: 245 seconds]
11:12 -!- socketwench [c693c305@gateway/web/freenode/ip.198.147.195.5] has quit [Ping timeout: 245 seconds]
11:12 -!- jay-batson [6b00ff81@gateway/web/freenode/ip.107.0.255.129] has quit [Ping timeout: 245 seconds]
11:12 -!- socketwench [c693c305@gateway/web/freenode/session] has joined #drupal-wscci
11:12 -!- kylebrowning_ is now known as kylebrowning
11:12 <@Crell> The question is how much of that we can do before it becomes a security hole.  We'll have to check with the security team.
11:12 -!- socketwench [c693c305@gateway/web/freenode/session] has quit [Changing host]
11:12 -!- socketwench [c693c305@gateway/web/freenode/ip.198.147.195.5] has joined #drupal-wscci
11:12 <@Crell> Uh oh.  netsplit.
11:12 < pounard> Crell> I know, but creating the "optimized" compiler from a configuration file is already what does the compilation phase
11:12 -!- stevector [persch@gateway/palantir/session] has joined #drupal-wscci
11:12 < pounard> right now, explained this way, I don't see a benefit at all
11:12 < pounard> s/compiler/container (first sentence)
11:13 < EclipseGc> Crell: yeah if we want (as msonnabaum suggested) to allow a module to override all of core's classes, then we'll need a really early bootstrap knowledge of module dirs (bare minimum) and that made me think we should just cache that in a file that's super early loaded in the bootstrap
11:13 <@Crell> pounard: Basically it comes down to either 1) We have to run hook_boot on every request, period, which means loading up modules on every request, period; or 2) We can serialize the results of hook_boot to somewhere and just load that.
11:13 <@Crell> EclipseGc: Possibly with composer? ;-)
11:13 -!- trew [~kaare@14.39.202.84.customer.cdi.no] has quit [Quit: raid+1]
11:13 < pounard> Crell> and what is faster, call 10 functions or load a file then unserialize its content?
11:13 < EclipseGc> Crell: I keep saying we should probably seriously consider that
11:13 < EclipseGc> Crell: but it's neclimdul's battle as far as I'm concerned
11:14 <@Crell> pounard: The file, because the functions are not just functions, but DB calls and circular dependencies.
11:14 <@Crell> So, it sounds like we're mostly discussing the SF2-style DI.
11:14 <@Crell> Does anyone want to argue in favor of a service locator a la Pimple?
11:14 < Stalski> Will everything be registered in a module or could there be executions that are registered in other ways?
11:14 < EclipseGc> yeah and we just rewrite this file any time module status changes, it actually means we can probably kill the system table in favor of this file...
11:15 < fabpot> Crell: to be clear, you can use both Pimple and the sf2 container as a service locator
11:15 < EclipseGc> Crell: I am really enjoying the pimple approach in my experimenting
11:15 -!- joachim_ [~joachim_@188-223-15-136.zone14.bethere.co.uk] has quit [Quit: off to have cake, probably]
11:15 < fabpot> a DI container becomes just a service locator when you inject it almost everywhere
11:15 <@Crell> fabpot: Yes, but even one of these is going to be a shock for a lot of people.  Let's not hurt their brains too much. :-)
11:15 < EclipseGc> Crell: and the notion of having essentially a bootstrapped core object available to me everywhere is really tempting
11:15 < pounard> fabpot> I maybe am wrong, but is the SF2 container can't accept closures as services?
11:15 < pounard> s/is//
11:16 < pounard> does
11:16 <@Crell> Although that's a fair question.  If an object spawns an object which calls a service which calls a service which calls a service, and there is request-sensitive routing happening... Dear got then what? :-)
11:16 < batsonjay> http://kaiface.files.wordpress.com/2010/05/headache_skratch.jpg
11:16 < batsonjay> Oh, that was for @crell… ;-)
11:16 < fabpot> pounard: obviously not if you want to dump it to PHP, YAML, or XML
11:16 < fabpot> but if you need support for this feature, that is really easy to add
11:16 < EclipseGc> being able to just say $kernel['plugins']->getPluginInstance('core', 'block', array('config' => 'my_configured_block')); is really compelling
11:16 < pounard> fabpot> I did in custom code
11:16 <@Crell> EclipseGc: I don't think that requires an SL approach.
11:16 < pounard> fabpot> but most of the compilation code I saw was actually in the FrameworkBundle?
11:17 <@Crell> Plus, I do not like the Silex-style "application is its own DIC" approach.  I don't think that would work for Drupal.
11:17 < fabpot> pounard: the framework bundle uses the compilation phase a lot (so it defined a lot of compiler passes), but the compilation feature is part of the component
11:17 < EclipseGc> Crell: and $kernel['request'] is my request object, $kernel['context'] is anything that's been shoved into the context object… I like it :-)
11:18 < pounard> fabpot> okay, it definitely lacks some bits of documentation then :) I saw you were really active writing it
11:18 < neclimdul> super early composer.json magic should probably be ignored at this point. getting any sort of acceptance would be a big step for d8.
11:18 < EclipseGc> Crell: well can you make the "this won't work for Drupal" argument for my sake?
11:18 < EclipseGc> Crell: cause I want to understand why
11:18 < EclipseGc> Crell: since I'm copying a lot of Silex approach here
11:18 < fabpot> pounard: yes, I know we are lacking some docs. If you have any question, please don't hesitate to send me emails
11:18 <@Crell> Silex is intended more for dedicated app development.  Drupal is much more sideways than that.
11:19 < pounard> fabpot> the security component was the worse one, but now I finally get it bits by bits
11:19 <@Crell> I ma be wrong, but I think in practice separating the kernel from the DIC will give us more flexibility and testability.
11:19 < fabpot> Crell: +1
11:19 < EclipseGc> how?
11:19 < EclipseGc> just so I understand the shortcomings
11:20 < EclipseGc> Crell: I mean I'd like to mock this up by Boston
11:20 < EclipseGc> and I'm willing to put in the time, but I have to understand the approach
11:20 <@Crell> One object = one responsibility.
11:20 <@Crell> A DIC/SL is "to be a big pseudo-array of things that do things".
11:20 <@Crell> The Kernel is "to be a front-end to the application".
11:21 < EclipseGc> Crell: ok, well would the DIC contain our request, context and response? or is that the responsibility of the kernel?
11:21 <@Crell> I wouldn't build a CMS with Silex.  I am considering it for a git browsing application, but that wouldn't be extensible.
11:21 <@Crell> I'm not sure if the request goes in the DIC or separately at the moment.  fabpot?
11:21  * EclipseGc waits expectantly
11:21 <@Crell> SF2 doesn't use a pre-created response, it creates it in the controller and returns it.  (Which we may or may not want to copy.  At the moment I am looking at that same model, but could be convinced otherwise.)
11:22 < fabpot> this is the hard part
11:22 <@Crell> Naturally. :-)
11:22 < EclipseGc> we tend to find the hard parts quickly ;-)
11:22 < fabpot> the Symfony2 kernel is re-entrant, which means that one instance of a kernel and one container can serve more than one request
11:22 < fabpot> so, whenever we start handling a request, we enter a new request scope and we store the request in the container
11:23 <@Crell> For ESI reasons I suspect we will have to be as well.
11:23 < fabpot> at the end of the request handling, we leave the scope and everything related to the current request are thrown away so that you can start handling a new request without "old" objects
11:23 < fabpot> yes, this is mainly to support ESI with the Symfony2 built-in reverse proxy
11:23  * batsonjay concludes this is a conversation he can add zero value to, and goes to lunch, wishing all diligent participants Good Wisdom!
11:24 < fabpot> because if you are using Varnish, then you don't have many requests per PHP process anymore
11:24 <@Crell> Exactly.
11:24 <@Crell> Asynchronous block rendering is a major feature we're going for.
11:24 < EclipseGc> yup
11:24 < Stalski> that'll be great :)
11:24 <@Crell> fabpot: So you're saying that the request object needs to be separate from the DIC for that to work?
11:25 -!- batsonjay [~batsonjay@mobile-198-228-193-035.mycingular.net] has left #drupal-wscci []
11:25 < fabpot> no, just that the request is injected into the container when we enter a new request scope
11:25 < fabpot> and removed from it when we have finished handling it (basically when we have a response object)
11:25 < EclipseGc> yeah, but couldn't we do that in pimple by simply not sharing the request closure? (so new at this forgive my ignorance)
11:26 <@Crell> So the request is stacked, essentially.
11:26 < pounard> and scopes work as fifos
11:26 < fabpot> so the request is not configured via the container
11:26 < pounard> filo
11:26 < fabpot> EclipseGc: no, that would be near to impossible to have this kind of support in Pimple (without duplicating a lot of code from the Symfony2 code)
11:27 < EclipseGc> fabpot: ok
11:27 <@Crell> Why is that?
11:27 < pounard> fabpot> when you are using the ContainerBuilder, does it replace the Container?
11:28 < pounard> so you don't proxy a Container and you merge both the Container and the Compiler?
11:28 < fabpot> pounard: yes
11:29 < pounard> ok
11:29 -!- jstanton617 [~jim@bherald-srx220.cust.e-xpedient.com] has quit [Read error: Connection reset by peer]
11:29 < fabpot> sorry guys, but I need to go now. As I said before, I'm available anytime if you need some help.
11:29 <@Crell> fabpot: Thanks for coming!
11:29 < EclipseGc> indeed
11:29 <@Crell> Although I had more questions for you. ;-)  When are you usually online?
11:29 -!- jstanton617 [~jim@bherald-srx220.cust.e-xpedient.com] has joined #drupal-wscci
11:29 < pounard> fabpot> thanks
11:29 < fabpot> Crell: Jabber works best for me
11:30  * EclipseGc wonders if there's a #fabpot channel
11:30 <@Crell> hehe.
11:30 -!- fabpot [~fabpot@symfony/developer/fabpot] has quit [Quit: fabpot]
11:30 <@Crell> fabpot: Can you PM me your preferred address?  (Or here if you don't mind everyone knowing.)
11:30 < ksenzee> too late, he left
11:30  * EclipseGc guesses it's fabpot
11:30 <@Crell> Jabber isn't a single namespace. :-)
11:30 <@Crell> Anyway, moving on.
11:30 < EclipseGc> #fail
11:31 <@Crell> No, #win.  Jabber is distributed by design.
11:31 <@Crell> It's more like email.
11:31 < EclipseGc> yes, but no guessing :-(
11:31 < pounard> actually anything distributed #wins
11:31 <@Crell> So, moving on...
11:31 <@Crell> It sounds like we're leaning toward DI, not SL?
11:31  * Crell is somewhat surprised by that...
11:32 <@Crell> I would now like to discuss user stories.
11:32 <@Crell> We've all done user stories before, right?
11:32 < pounard> what's SL?
11:32 < socketwench> Was wondering that myself....
11:32 <@Crell> Service Locator (pass a pimple object to everything)
11:32 -!- dixon_ [~dixon_@178.152.20.21] has quit [Quit: dixon_]
11:32 <@Crell> Vs Dependency Injection (fancier object that calls methods to setup dependent objects for you).
11:32 < pounard> for human beings, DIC and SL actually is the same interface
11:33 -!- skyred [~skyred@116.233.128.154] has joined #drupal-wscci
11:33 < pounard> and if we use SF2 DIC in order to proceed to a compilation phase, we actually end up with a pre-configured SL
11:34 <@Crell> Just to make it more interesting. :-)
11:34 <@Crell> Anyway...
11:34 <@Crell> Please go here: http://piratepad.net/y3Txl6zQg1
11:34 < pounard> yes, I'm still really not convinced by SF2 compiler at all
11:34 < socketwench> Dang. Firewalled.
11:34 < pounard> but that's an opinion
11:34 <@Crell> This is a list of user stories that I started putting together with catch and cosmicdreams a while back.
11:35 <@Crell> I want to take the next 15-20 min or so to further refine it.
11:35 <@Crell> This is our user stories *for developers writing code* that depends on other "stuff".
11:36 < EclipseGc> Crell: did you copy and paste this from a previous pad?
11:36 -!- jtsnow [~jtsnow@199.16.150.186] has joined #drupal-wscci
11:36 <@Crell> Yes.
11:36 < EclipseGc> Crell: cause this was mine: As a site builder, I want to reuse pre-existing administrative components at new urls with no hassle.
11:37 < cboden> Is there any plan on session handling for Drupal 8 yet?
11:37 < EclipseGc> Crell: and it was really the only big thing that I felt wasn't there at the time
11:37 <@Crell> cboden: Depends if the SF2 session handling improves.
11:37 < cboden> it does
11:37 < cboden> overhaul in 2.1
11:37 <@Crell> cboden: Ah, that did happen?  Did it address the flash issue? :-)
11:37 <@Crell> EclipseGc: that's Context Admin basically, right?
11:37 < cboden> yes, and other issues
11:37 < EclipseGc> cboden: I'd like to wrap a number of things at that level with a plugin system so that we ship something and you can easily change it out for something else
11:37 < EclipseGc> Crell: yes
11:37 <@Crell> cboden: Spiffy.  We'll have to look into that soon.
11:38 -!- rteijeiro [~rteijeiro@95.62.41.19] has quit [Remote host closed the connection]
11:38 <@Crell> EclipseGc: If you can figure out how to phrase that as a DX story, please add it. :-)
11:38 <@Crell> EclipseGc: The SF2 session system is already swappable, although I don't know the details of exactly how.
11:39 -!- rteijeiro [~rteijeiro@95.62.41.19] has joined #drupal-wscci
11:39 -!- hejrocker [~heyrocker@82.214.246.221] has joined #drupal-wscci
11:39 < cboden> SF Session (2.1) is written to an interface that _can_ be used - but also fixes issue where it handles session, but stays out of the way when developers use the $_SESSION array
11:40 <@Crell> Nice1
11:40 < EclipseGc> Crell: yeah, honestly I'd rather wrap the plugin system around it so that we have consistency, but I digress
11:40 <@Crell> cboden: There's an open issue somewhere about that, if you want to take it over.
11:40 <@Crell> I'd love to be able to leverage it.
11:40 < cboden> Anyway, I ask as the story "As  a test writer, I want to replace the session storage with an array held  in PHP memory, so I can write unit tests for functionality depending on  sessions."
11:40 < cboden> There are rather large changes coming to Symfony2.1 Session handlers." -- wanted to comment about the 2.1 changes involved a Mock session object for their unit tests
11:41 < cboden> Crell I'll take a look.  Can you provide me w/ a link to put me in the right direction?
11:41 < EclipseGc> Crell: how's that from a DX perspective?
11:41 <@Crell> So anyone else besides EclipseGc and cboden: Thoughts on the user stories?  Questions?  Things toa dd?
11:41 <@Crell> EclipseGc: Hm, kinda over-generic. :-)
11:41 < EclipseGc> Crell: that's the point ;-)
11:41 <@Crell> Hard to execute against.
11:41 < pounard> almost too much :)
11:41 < EclipseGc> Crell: you want me to get super specific about what it would look like?
11:42 <@Crell> No, a user story should be something that we can execute against.
11:42 <@Crell> Vis, we can say definitively if we did/did not achieve it, or to what extent we did.
11:43 < EclipseGc> better?
11:43 <@Crell> cboden: http://drupal.org/node/335411 - Read the summary, then skip to comment 46.  The stuff before that is old thoughts you can ignore.
11:43 < Druplicon> http://drupal.org/node/335411 => Switch to Symfony2-based session handling => Drupal core, base system, major, active, 80 comments, 33 IRC mentions
11:43 <@Crell> And the discussion after is based on SF 2.0, so if 2.1 changes things, great.
11:44 <@Crell> pounard: "Exploitation center"?  I think something is lost in translation there. :-)
11:44 -!- dixon_ [~dixon_@178.152.20.21] has joined #drupal-wscci
11:45 < pounard> yes, I defintely don't know how to translate it
11:45 <@Crell> EclipseGc: I still don't know what that says...
11:45 < pounard> is that clearer ? :)
11:46 < cboden> Thanks Crell, Druplicon.  I will read through and weigh in on that thread this evening.
11:46 <@Crell> pounard: Is that more what you're talking about?  The line I added below it?
11:46 < pounard> yes and no
11:46 -!- heyintern [~Haugen@static-213-115-3-58.sme.bredbandsbolaget.se] has joined #drupal-wscci
11:46 < pounard> it's related
11:46 <@Crell> cboden: There's a linked thread toward the end, too, that needs work.
11:47 < pounard> more like it
11:47 -!- rteijeiro [~rteijeiro@95.62.41.19] has quit [Ping timeout: 244 seconds]
11:47 <@Crell> socketwench: ksenzee neclimdul samkottler1 : Anyone else want to jump in here?
11:47 < Janusman> Crell: do you think a situation of deploying config changes to another server could apply in these stories?
11:47 <@Crell> Hm, probably.
11:47  * ksenzee reads backscroll
11:48 < Janusman> being that there is one about editing configuration without a UI
11:48 < pounard> Crell> something bothers me with a potential compilation phase: replacing components in configuration files might get tricky if we get to the point we have a lot of dependencies junk described in compiler input data
11:48 <@Crell> Janusman: How's that?
11:48 < Janusman> Crell: looks good =)
11:49 < socketwench> Mostly I'm lost. With DI I'd understand a bit what the code would look like, but not so much with SL.
11:49 <@Crell> pounard: I agree.  That's why I'm still squeamish about it, but I don't know if we can avoid it without introducing a dependency on hook_boot, modules, and the database.
11:49 <@Crell> socketwench: We've moved on a bit from that. :-)
11:49 < pounard> I'm not sure compilation is mandatory
11:49 < EclipseGc> Crell: I want blocks everywhere, how is this unclear through what I'm saying
11:49 <@Crell> But basically SL: $this->serviceLocator['foo']->doStuff();  DI: $this->foo->doStuff();
11:50 -!- rteijeiro [~rteijeiro@95.62.41.19] has joined #drupal-wscci
11:50 < pounard> where I was really shocked by SF2 is that some bundles actually gets really cryptic because of it
11:50 < socketwench> Ahhh, well. Not surprised. I'm at work, so I'm not devoting as much attention to this as I should.
11:50 < Janusman> don't see anything regarding "plugability" and AFAIK isn't that a big "thing" for this initiative? =)
11:50 < pounard> and component features becomes totally ofuscated because of it
11:50 <@Crell> But on the constructor: SL: __construct(ServiceLocator $services); DI: $o = new Thingie(); $o->setFoo($service->foo);
11:50 <@Crell> (In both cases, they'd be mostly automated by the central system.)
11:51 <@Crell> Janusman: Indeed.  Please elaborate.
11:51 < pounard> a DIC is a SL with setters more or less, I don't like to separate them
11:52 -!- Grayside [~abr@70-36-245-144.dsl.static.sonic.net] has joined #drupal-wscci
11:52 -!- amateescu_ [~amateescu@drupal.org/user/729614/view] has joined #drupal-wscci
11:52 < pounard> (and less features)
11:52 <@Crell> EclipseGc: More like that?
11:52 -!- amateescu [~amateescu@drupal.org/user/729614/view] has quit [Ping timeout: 248 seconds]
11:52 -!- amateescu_ [~amateescu@drupal.org/user/729614/view] has quit [Read error: Connection reset by peer]
11:52 < EclipseGc> Crell: errm… no not really
11:52 < Janusman> <- not that versed in the initiative, but I was expecting something mentioning enabling/disabling/exporting/overriding/etc configuration. perhaps that's an overlap with the CMI (same as my earlier comment)
11:53 <@Crell> Then I still don't know what you're saying. :-)  And really, is it a *DX* issue?
11:53 <@Crell> Remember, this isn't user stories for WSCCI, but just for DI/SL/etc.
11:53 < EclipseGc> Crell: it's imperative that this be both typical block content as well as things we don't consider blocks right now, we need a system strong enough to support output of any sort
11:53 <@Crell> Janusman: That's CMI's job.
11:53 < socketwench> Something about this reminds me of the BeOS API...
11:53 < Janusman> Crell: ok
11:54 <@Crell> For this doc, we are focused *only* on the DIC/SL question.
11:54 < EclipseGc> Crell: ok, fair enough it may not be DI/SL in that respect
11:54 -!- travelertt [~travelert@208.176.184.35.ptr.us.xo.net] has quit [Remote host closed the connection]
11:54 <@Crell> OK, let's remove both of those for now.
11:54 < EclipseGc> k
11:54 <@Crell> In terms of configuration, actually...
11:54 <@Crell> A given class's dependencies will never change without code changes.
11:55 -!- travelertt [~travelert@208.176.184.35.ptr.us.xo.net] has joined #drupal-wscci
11:55 <@Crell> What may change is the the class associated with a given service.
11:55 < EclipseGc> because hopefully we can pass that in
11:56  * Janusman changed "[strings] translated language of the site" to "language of the context"
11:56 < pounard> I was wondering who on earth would want to mix languages
11:56 < Janusman> a site can be multilingual
11:56 < pounard> there is indeed a difference between content language and tooling language, but content language is not handled by any API such as gettext
11:57 < pounard> and the context in WSCCI sense is different contextes in different portion of the page, not on different pages
11:57 -!- lsmith [~lsmith@77-58-147-243.dclient.hispeed.ch] has joined #drupal-wscci
11:57 < pounard> so IMO language is global in the runtime
11:57 -!- jherencia [~jherencia@68.160.220.87.dynamic.jazztel.es] has joined #drupal-wscci
11:58 <@Crell> Janusman: Da.
11:58 < Janusman> pounard: but don't we might have to switch language for the sake of unit testing?
11:58  * Janusman fails at typing
11:58 <@Crell> pounard: No it's not, because each block/controller may be in a different language for UI *or* content.
11:58 <@Crell> The word global is not allowed anywhere in this document. :-)
11:59  * neclimdul got distracted eating
11:59 < pounard> Crell> yes, we could, but I was thinking of it, and IMHO, this will never happen :)
11:59  * Crell can think of multiple use cases.
11:59 < pounard> not voluntarely anyway
11:59 < pounard> Crell> for content, yes, I could understand, but for UI?
12:00  * EclipseGc is trying to make a distinction here, i.e. UI and content are NOT different things
12:00 < pounard> EclipseGc> they are
12:00 < EclipseGc> soon as we accept that, the easier this becomes
12:00 <@Crell> pounard: Conceptually we should allow it.
12:00 < EclipseGc> no they are not
12:00 < pounard> yes they are :)
12:00 <@Crell> EclipseGc: They are.  Ask Gabor.
12:00 < EclipseGc> pounard: you keep that separation in D8 and I'll hunt you down myself
12:00 < EclipseGc> Crell: you too
12:00 < pounard> EclipseGc> lol
12:01 <@Crell> A site in 3 languages, but the admin speaks only one and wants his admin UI in one language.
12:01  * Crell has built such sites, much to his dismay.
12:01 < pounard> EclipseGc> seriously, a user might want to see the "edit" link in its own language, but wants to review the spanish content
12:01 < pounard> they are different
12:01 < pounard> and you don't share content translation via gettext, for example, it would be a huge error
12:01 <@Crell> OK, getting BACK on topic...
12:01 -!- jherenci_ [~jherencia@68.160.220.87.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
12:01 < EclipseGc> that's a difference in that language of content and language of UI might be different, not that the content and UI output themselves are different components
12:02 <@Crell> neclimdul: Good, now that you're done eating, any user story feedback? ;-)
12:02 < pounard> Crell> I think this list is already big enought, we have work for the next 2 years
12:02 < neclimdul> Crell: they're great tools. we should have a lot
12:02  * Crell sighs.
12:02 <@Crell> pounard: Well, the idea is to take the stories and use them to design an API that can hit as many of them as possible with as little effort as possible.
12:02  * neclimdul is skimming the backscroll for context
12:03 < hejrocker> can you make that assumption? what if you want to localize some of the content to a user's native language (specified at registration) which may be differnet than the site's current default language?
12:03  * Crell gags hejrocker.
12:03 < ksenzee> I read over the list and don't have anything to add
12:03 < pounard> font changes while reading is awful
12:03 < hejrocker> i guess that is irrelevant to context at that point
12:03 < Janusman> Nice list. Hey list... how you doin'?
12:04 <@Crell> hejrocker: We're not talking context, we're talking service injection. ;-)
12:04  * EclipseGc is a little fuzzy on all the terms we've thrown out at this point
12:04 < EclipseGc> heh
12:05 -!- Stalski [~stalski@dD5768671.access.telenet.be] has left #drupal-wscci []
12:05 <@Crell> One thing I'm still unsure of in either approach is nested services.
12:05 -!- hejrocker [~heyrocker@82.214.246.221] has quit [Quit: Leaving]
12:05 < EclipseGc> use case?
12:05 <@Crell> Eg, different cache bins, different database connections, etc.
12:06 -!- sun [~sun@drupal.org/user/54136/view] has joined #drupal-wscci
12:06 -!- davereid is now known as davereid|lunch
12:06  * neclimdul considers organizing those stories a bit
12:07 <@Crell> neclimdul: Feel free.
12:07 < pounard> neclimdul++
12:07 < pounard> Crell> often, nested services are linked to the service business, I don't see it being a generic use case
12:08 <@Crell> pounard: Perhaps, but we have a lot of them.
12:08 <@Crell> At least I think we do... :-)
12:08 < pounard> e.g. cache bin is a nested service, database too, but database has an obvious default and you don't want to use anyother one except for really specific purposes while cache you will use it a lot more
12:08 < neclimdul> bouncing back and forth between users was confusing me
12:08 < pounard> Crell> we have cache, for sure, but do we have that much more?
12:09 <@Crell> DB.
12:09 < pounard> "real names in etherpad"--
12:09 < pounard> Crell> yes, but in most cases, you don't want to hit another DB, for cache, it's the opposite
12:09 < neclimdul> oh right... vague cars 2 references as etherpad nicks --
12:09 <@Crell> lol
12:10 < pounard> oh that was you :)
12:10 < neclimdul> yeah, aparently it remembers when you put in a joke name 2 weeks ago and keeps it for you
12:10 < pounard> Crell> you put a "user" disclaimer on top, but we don't use user anywhere
12:10 < pounard> neclimdul> lol
12:10 <@Crell> pounard: If we use the DI/SL for plugin instantiation, there could be lots of them.
12:11 <@Crell> Although that logic is complex enough that we may need the plugin mapper itself to be the service.
12:11 < neclimdul> pounard: user as in "user stories"
12:11  * Crell isn't sure.
12:11 < pounard> Crell> maybe indeed
12:12  * EclipseGc needs to get back to code
12:12 < EclipseGc> ping me if you need me
12:12 < pounard> I am really hungry
12:12 < pounard> and tired
12:15  * neclimdul thinks the meeting just ended
12:15 < pounard> Crell> "As a site builder, I want to reuse pre-existing administrative components at new urls with no hassle." does it make sense?
12:15 < pounard> as a developer, I would, but as a site builder?
12:16 <@Crell> Yeah, not sure if that's in scope.
12:16 < neclimdul> pounard: that's EclipseGc
12:16  * neclimdul recognizes context_admin when he see's it
12:16 <@Crell> hehehe.
12:16 < pounard> neclimdul> ahah :)
12:16 < EclipseGc> heh
12:16 < EclipseGc> yeah that's totally me, if you want to yank that, feel free
12:16 < pounard> I think that's not in scope
12:17 < pounard> but as a developer, it makes sense
12:17 < pounard> reusing components
12:17 < Janusman> Amazed there's not a user story in there that mentions ponies.
12:17  * EclipseGc tried to format that as a developer and Crell didn't like it
12:17 < neclimdul> well, its peripheral scope
12:17 < pounard> Janusman> now there is
12:17 < Janusman> LOL
12:18 < pounard> just kidding I'm removing it
12:18 < Janusman> Yes, that kind of differentiation is always difficult.
12:18 < neclimdul> it doesn't need to be in the list but i'm sure eclipse will be actively keeping it in mind so it'll get applied
12:18 < pounard> Crell> interesting those user stories, we almost need to put them somewhere in a specific tool for handling them
12:18 < pounard> in the sense easily modifiable
12:19 <@Crell> I don't know if anyone is doing user-story-based API development.
12:19 <@Crell> I'm experimenting with it as a concept.
12:19 < pounard> yes, for API it's hard to do
12:19 < pounard> for a full project it makes senses, but API often derivate from a single need in the beginning
12:20 < Janusman> Seems natural to do user stories actually. I mean, DX, right?
12:20  * Janusman goes have lunch
12:20 < EclipseGc> neclimdul: I'm just trying to make core devs think properly
12:20 -!- Janusman is now known as Janusman_lunch
12:20 < neclimdul> pounard: you may not be able to predict but you can just change the API and if anyone cares they'll make an issue.
12:20 < pounard> I fixed my question
12:20 < pounard> yes
12:20 < neclimdul> that's surely a good way of doing things :P
12:20 < pounard> neclimdul> that's issue driven development :)
12:21 <@Crell> neclimdul: That's what we've done to date.
12:21 < pounard> we could title that "anger-driven development"*
12:21 <@Crell> The result is Drupal 7 and Render API.
12:21 < neclimdul> Crell: well > D5 we've made a destinct effort not to have that be the case post release but yeah
12:22 < pounard> I have to go though, I'm sad I don't have much time on IRC those days, I'm definitely more efficient within the day than in the night
12:22 < pounard> half I'm saying since I arrived an hour ago is crap
12:22 < pounard> good bye