IRCLogs20110324 (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of IRCLogs20110324

lsmith (IP:
03/25/11 08:13:39 (7 years ago)



  • IRCLogs20110324

    v0 v1  
     1= Summary = 
     5== Response sub-classes vs. exceptions for HTTP status codes == 
     7== Review: Services naming == 
     9== Whats missing for RC1? == 
     11== why parameters.ini? == 
     13== "core" dev meeting in Paris == 
     15== Naming collisions with Bundles == 
     17== Cache warming == 
     19== mongodb session storage == 
     21= IRC logs = 
     23Mar 24 12:00:46 <lsmith>        so lets go 
     24Mar 24 12:01:09 <lsmith>        Response sub-classes vs. exceptions for HTTP status codes: 
     25Mar 24 12:01:12 <lsmith>        fabpot: ping 
     26Mar 24 12:01:18 <lsmith>        kriswallsmith: ping 
     27Mar 24 12:01:23 <fabpot>        pong 
     28Mar 24 12:01:27 <kriswallsmith> pong 
     29Mar 24 12:01:30 <beberlei>      oink 
     30Mar 24 12:01:48 <lsmith>        i guess both fabpot and kriswallsmith now think we shouldnt do this 
     31Mar 24 12:01:58 <kriswallsmith> yes, it takes control away from the user 
     32Mar 24 12:02:04 <fabpot>        I created the 2 pull requests because I was not sure 
     33Mar 24 12:02:05 <lsmith>        leaving me (and maybe Seldaek) who also think we should do this 
     34Mar 24 12:02:25 *       johnkary ( has joined #symfony-dev 
     35Mar 24 12:02:29 <fabpot>        I think this is more a documentation problem, than a technical one 
     36Mar 24 12:02:33 <lsmith>        kriswallsmith: well we direct things to a central place by default 
     37Mar 24 12:02:46 <jmikola|w>     is the argument against using sub-classes? 
     38Mar 24 12:02:54 <jmikola|w>     i see nothing in the ML link other than Jordi's +1 
     39Mar 24 12:03:03 <Seldaek>       jmikola|w: it's in the PR 
     40Mar 24 12:03:08 <fabpot>        jmikola|w: everything is in the PRs 
     41Mar 24 12:03:08 <kriswallsmith> the centralized solution is there unless the user opts out of it by returning a response 
     42Mar 24 12:03:25 <kriswallsmith> so, +1 for addressing in documentation 
     43Mar 24 12:03:45 <Seldaek>       and for my part, I'm not sure anymore if it's a good idea.. I think if we tell people to use exceptions, then it's ok if 4xx/5xx responses don't follow the same path, those are for more advanced use cases imo where you want to control everything 
     44Mar 24 12:04:14 <Seldaek>       and in that case, I don't want my web service to return an exception page, I want to return a 405 and that's it 
     45Mar 24 12:04:16 <lsmith>        johanness: ping 
     46Mar 24 12:04:31 <jmikola|w>     is johanness' point about firewall needing to catch its access denied exception still valid?  or was he opting to use security-specific exceptions instead 
     47Mar 24 12:04:32 <johanness>     i don't see the point in doing that via documentation. if we don't want users to return error responses then we should disallow it 
     48Mar 24 12:05:11 <lsmith>        johanness: well its not that we dont want them to do that 
     49Mar 24 12:05:14 <fabpot>        johanness: that's what my PR does 
     50Mar 24 12:05:17 <lsmith>        its just that we want to prevent surprises 
     51Mar 24 12:05:19 <Seldaek>       johanness: I don't see why it should be prevented, it just means you don't use the framework exception handler, but an error response isn't really an exception, it's just a response to the client to tell it that something went wrong 
     52Mar 24 12:05:29 <lsmith>        but i can live with it being handled by documentation .. 
     53Mar 24 12:05:39 <lsmith>        though i think we could just as well document how to undo the default 
     54Mar 24 12:05:46 <kriswallsmith> i don't think users will be surprised if the core.exception event isn't fired when an exception isn't thrown 
     55Mar 24 12:05:55 <johanness>     fabpot, yeah i would change that to always throw a 500 exception saying that the user should throw an exception instead of return a response 
     56Mar 24 12:06:06 <lsmith>        but i guess the PR handles hiding a user error while forcing advanced users to change defaults 
     57Mar 24 12:06:17 <Seldaek>       kriswallsmith: yeah that's definitely true, the current way (pre-PR) is at least straightforward 
     58Mar 24 12:06:27 <kriswallsmith> i don't think that level of strictness is necessary johanness 
     59Mar 24 12:06:54 <johanness>     kriswallsmith, but we want users to do that 
     60Mar 24 12:07:07 <johanness>     why should we put that into the documentation otherwise? 
     61Mar 24 12:07:07 <lsmith>        johanness: the question is do we? 
     62Mar 24 12:07:11 <kriswallsmith> it doesn't matter if they throw an exception or a response, it's up to them 
     63Mar 24 12:07:14 <jmikola|w>     even internally, sf2 will not convert exceptions into error-specific response subclasses... it'll just be response objects with appropriate 4xx or 5xx error codes? 
     64Mar 24 12:07:31 <lsmith>        for example returning a 405 response .. could be a way for json/xml requests to by pass the exception listener 
     65Mar 24 12:07:38 <lsmith>        since most likely you dont want it triggered there 
     66Mar 24 12:07:56 <kriswallsmith> we shouldn't for a user into more abstraction 
     67Mar 24 12:08:01 *       bschussek has quit (Quit: May the force be with you) 
     68Mar 24 12:08:08 <fabpot>        jmikola|w: the question is not whether we need to create sub-classes or not; it's if we force developer to use exception for 4xx/5xx 
     69Mar 24 12:08:24 <lsmith>        we should also not just focus on this aspect .. 
     70Mar 24 12:08:25 <lsmith> 
     71Mar 24 12:08:26 <jmikola|w>     reading through PR370, i'm in favor of core.exception functioning like core.view... it only steps in if an exception is received; i don't think strictness is necessary 
     72Mar 24 12:08:50 <lsmith>        pull 370 is fairly clear cut .. you either favor one or the other 
     73Mar 24 12:08:54 <johanness>     kriswallsmith, imo if we keep the flexibility, there is no point in advocating one solution over the other, e.g. we shouldn't put anything into the documentation 
     74Mar 24 12:08:58 <lsmith>        PR 369 is a bit trickier from my POV 
     75Mar 24 12:09:18 <jmikola|w>     fabpot: there seem to be many more 4xx and 5xx codes than we'd have exceptions for out of the box anyway... it might be limiting to mandate exceptions 
     76Mar 24 12:09:53 <fabpot>        jmikola|w: read my post on the ML, everything is explained there 
     77Mar 24 12:10:46 <lsmith>        johanness/fabpot: did you find a common ground on PR 369? 
     78Mar 24 12:10:51 <lsmith>        and if so .. what is it? 
     79Mar 24 12:11:02 *       kertz has quit (Ping timeout: 240 seconds) 
     80Mar 24 12:11:09 <jmikola|w>     fabpot: yes, i see the list of what exceptions you're choosing to implement 
     81Mar 24 12:11:10 <fabpot>        lsmith: not yet 
     82Mar 24 12:11:19 <johanness>     we first need to settle on a general strategy imo 
     83Mar 24 12:11:23 <lsmith>        ok 
     84Mar 24 12:11:47 <kriswallsmith> should be be concerned that http exceptions can be thrown from anywhere in the application? 
     85Mar 24 12:11:54 <kriswallsmith> i.e. from the model? 
     86Mar 24 12:11:55 <lsmith>        so lets vote on PR 370 .. solve this by documentation or by forcing all 4x, 5x responses through the exception listener? 
     87Mar 24 12:12:07 *       henrikbjorn ( has joined #symfony-dev 
     88Mar 24 12:12:19 <johanness>     lsmith, what does "solve this by documentation" mean? 
     89Mar 24 12:12:26 <kriswallsmith> is this a community decision? 
     90Mar 24 12:12:42 <lsmith>        johanness: document that if you want the exception listener triggerd .. throw an exception 
     91Mar 24 12:12:51 <lsmith>        if you dont ... return a response 
     92Mar 24 12:13:02 *       M00nShield has quit (Ping timeout: 240 seconds) 
     93Mar 24 12:13:30 <iAsterisk>     why should response go through an exception listener? 
     94Mar 24 12:13:43 <fabpot>        ok, let's stop this discussion, it's going nowhere 
     95Mar 24 12:14:00 <iAsterisk>     from the outside it looks confusing. 
     96Mar 24 12:14:04 <fabpot>        I'm going to close PR 370 and let things as they are now 
     97Mar 24 12:14:05 <lsmith>        yes .. thats why i was asking for a vote 
     98Mar 24 12:14:10 <lsmith>        ok 
     99Mar 24 12:14:11 <kriswallsmith> sounds good, let's move on 
     100Mar 24 12:14:24 <lsmith>        what about PR 369? 
     101Mar 24 12:14:31 <lsmith>        anything we can discuss here to move things along? 
     102Mar 24 12:15:07 <lsmith>        ok .. since nobody is speaking up 
     103Mar 24 12:15:09 <lsmith>        next topic 
     104Mar 24 12:15:11 <lsmith>        Review: Services naming: 
     105Mar 24 12:15:17 <kriswallsmith> i'm still recusing myself from all security stuff 
     106Mar 24 12:16:10 <lsmith>        i guess here the main question is if anyone is willing to spear head this? 
     107Mar 24 12:16:20 <lsmith>        aka look through the list that jordi generated 
     108Mar 24 12:16:22 <Seldaek>       yeha, I did my part with the grepping :p 
     109Mar 24 12:16:31 <henrikbjorn>   define the naming, wasnt it about making some of them less verbose ? 
     110Mar 24 12:16:32 <lsmith>        and try to find common naming patterns 
     111Mar 24 12:16:35 <lsmith>        maybe document them 
     112Mar 24 12:16:36 <fabpot>        lsmith: I will do that, it's on my todo list already 
     113Mar 24 12:16:43 <lsmith>        ok 
     114Mar 24 12:16:49 <lsmith>        then there is nothing to discuss there either? 
     115Mar 24 12:16:49 <everzet>       cool 
     116Mar 24 12:17:02 <Seldaek>       yeah I think it's good if fabpot can find time to do it, he has the best overview of everything 
     117Mar 24 12:17:09 *       DrRotmos ( has joined #symfony-dev 
     118Mar 24 12:17:18 <lsmith>        then moving on .. 
     119Mar 24 12:17:24 <kriswallsmith> re: doctrine.odm.mongodb.default_document_manager, should we create a persistence manager-manager? 
     120Mar 24 12:17:27 <Seldaek>       fabpot: if you manage to pull out some naming-conventions out of it to add to the docs, even better 
     121Mar 24 12:17:47 <everzet>       Seldaek: +1 
     122Mar 24 12:17:49 <Seldaek>       'cause I've seen lots of horrible things done in bundles by random people 
     123Mar 24 12:17:50 <fabpot>        Seldaek: I will try to find some naming conventions for sure 
     124Mar 24 12:17:52 *       kertz (~kertz@ has joined #symfony-dev 
     125Mar 24 12:18:02 <lsmith>        next topic then: Whats missing for RC1? 
     126Mar 24 12:18:11 <lsmith>        not sure if anything has changed since last week really 
     127Mar 24 12:18:16 <henrikbjorn>   kriswallsmith: would be nice, but confusing if you use odm and orm at the same time 
     128Mar 24 12:18:17 <Seldaek>       forms, but nvm :) 
     129Mar 24 12:18:22 <kriswallsmith> i think all public services should use only _ no . 
     130Mar 24 12:18:38 <Seldaek>       kriswallsmith: ah weird, I liked the dots 
     131Mar 24 12:18:55 <Seldaek>       I think they denote nesting much better than underscores 
     132Mar 24 12:18:56 <fabpot>        I have converted many components to private usage 
     133Mar 24 12:18:56 <jmikola|w>     kriswallsmith: dots are helpful for namespacing 
     134Mar 24 12:18:57 <everzet>       kriswallsmith: dots is better 
     135Mar 24 12:19:06 <everzet>       kriswallsmith: *ARE better 
     136Mar 24 12:19:11 <fabpot>        but some still need to be done: Serializer, Form, and Validation 
     137Mar 24 12:19:20 <kriswallsmith> we should have very few public services 
     138Mar 24 12:19:22 <Seldaek>       aye, it's on my todo 
     139Mar 24 12:20:05 <Seldaek>       kriswallsmith: still, it just feels more natural to use <some_ns>.<name>, looks like twig variables 
     140Mar 24 12:20:08 <henrikbjorn>   private = cant be changed or ? 
     141Mar 24 12:20:11 <lsmith>        anything else that has changed since last week in terms of getting to RC1? 
     142Mar 24 12:20:21 <lsmith>        fabpot: one question .. so the next release will be called beta1? 
     143Mar 24 12:20:23 <lsmith>        or RC1? 
     144Mar 24 12:20:25 <Stof>  henrikbjorn: can't be retrieved at runtime 
     145Mar 24 12:20:31 <henrikbjorn>   ok 
     146Mar 24 12:20:34 <lsmith>        and if beta1 .. will we also have an RC phase? 
     147Mar 24 12:20:38 *       mapi_ has quit (Ping timeout: 255 seconds) 
     148Mar 24 12:20:40 <everzet>       lsmith: RC without beta's is quite extreme :-) 
     149Mar 24 12:20:42 <fabpot>        lsmith: beta1 as we won't have the service renames for instance 
     150Mar 24 12:20:43 <lsmith>        just because i have seen some people wondering 
     151Mar 24 12:20:51 <lsmith>        ok 
     152Mar 24 12:20:54 <everzet>       lsmith: but i think our current PR's is already beta's 
     153Mar 24 12:20:55 <fabpot>        some betas and then some RCs 
     154Mar 24 12:21:19 <lsmith>        ok .. then moving on to the next topic -> why parameters.ini? 
     155Mar 24 12:21:21 <fabpot>        everzet: beta means that all features are there but with bugs ;) 
     156Mar 24 12:21:31 <Seldaek>       fabpot: ah right, something I wanted to mention, I've seen so many people asking when/what about the final, I think they deserve an update on the official blog to say what's the current state 
     157Mar 24 12:21:45 <Seldaek>       because we are all up to speed here, but the users at large aren't 
     158Mar 24 12:21:45 <everzet>       fabpot: it's strange, but i was always thought it is RC :-D 
     159Mar 24 12:22:04 <fabpot>        everzet: RC means that we won't break BC 
     160Mar 24 12:22:14 *       nostrzak ( has joined #symfony-dev 
     161Mar 24 12:22:21 <lsmith>        fabpot: basically many of us have been wondering why the SE uses ini format 
     162Mar 24 12:22:24 <fabpot>        Seldaek: right, I will do that when announcing the beta1 next week 
     163Mar 24 12:22:32 <lsmith>        what is the motivation for this? 
     164Mar 24 12:22:34 <Seldaek>       ok cool 
     165Mar 24 12:22:43 <lsmith>        given the flexibility of ini parsing in php 5.3 .. 
     166Mar 24 12:22:48 <everzet>       fabpot: :-D Ok. It's just me. I've thought that beta is just betta than nothing... 
     167Mar 24 12:22:49 <fabpot>        lsmith: because some people don't like YAML, some others don't like XML, and many don't like PHP for configuration 
     168Mar 24 12:22:50 *       rouffj ( has joined #symfony-dev 
     169Mar 24 12:22:52 <lsmith>        i dont really see much difference between ini and yaml 
     170Mar 24 12:23:11 <fabpot>        and I don't want people to not use Symfony just because the first thing the see is a YAML/XML file 
     171Mar 24 12:23:34 <Stof>  then do all config in ini, not just one of the files :) 
     172Mar 24 12:23:40 <lsmith>        well and what about the people that dont like ini for app config? 
     173Mar 24 12:23:57 <henrikbjorn>   well they can see all formats 
     174Mar 24 12:24:04 <henrikbjorn>   so they know they can choose whatever they want 
     175Mar 24 12:24:13 <everzet>       lsmith: if you know how to configure Symfony2 app in yaml - you will be able to remove this ini simple 
     176Mar 24 12:24:18 <lsmith>        i think adding a 4th format is adding confusion 
     177Mar 24 12:24:27 <fabpot>        I think everybody can understand the goal of a simple ini file, it's just to be able to configure the required settings 
     178Mar 24 12:24:29 <everzet>       lsmith: but if you don't (very begginer) - ini is a good starting point 
     179Mar 24 12:25:02 <everzet>       lsmith: i think it's not about 4th format. It's about single configuration file for beginners. 
     180Mar 24 12:25:06 <pgodel_work>   an explanation would aid in avoiding confusion 
     181Mar 24 12:25:32 <lsmith>        i think our flexibility with formats is a plus 
     182Mar 24 12:25:33 <srohweder>     thfo the beginners you can include one yml and hide the complicated stuff in imports 
     183Mar 24 12:25:38 <Seldaek>       I guess the ini file is ok for standard distro maybe, but shouldn't be there in the others 
     184Mar 24 12:25:41 <ajessu>        I like it for beginners.. it's easy to copy and paste (think tabs vs spaces in yaml) and very easy to understand right away 
     185Mar 24 12:25:43 <lsmith>        but at the same time its confusing as hell for beginners already 
     186Mar 24 12:25:44 <ajessu>        just to get started 
     187Mar 24 12:26:11 <lsmith>        sure an ini file is something they will have seen with their php.ini 
     188Mar 24 12:26:12 <pgodel_work>   but it is confusing because there is no explanantion and it was a suprise for us 
     189Mar 24 12:26:24 <Seldaek>       on the other hand, all the sf1 users are used to yaml.. 
     190Mar 24 12:26:31 <everzet>       lsmith: yeah. We need to tell them not to open other *.yml stuff before they'll become mature 
     191Mar 24 12:26:33 <pgodel_work>   but I think it is easily addressable by documeting properly 
     192Mar 24 12:26:34 <lsmith>        anyway .. 
     193Mar 24 12:26:42 <lsmith>        either we vote on it .. or let fabpot decide 
     194Mar 24 12:26:46 <lsmith>        no reason to keep talking about this 
     195Mar 24 12:26:47 <henrikbjorn>   +1 
     196Mar 24 12:26:51 <everzet>       +1 
     197Mar 24 12:26:51 <henrikbjorn>   for ini 
     198Mar 24 12:27:00 <fabpot>        +1 
     199Mar 24 12:27:01 *       old_sound has quit (Quit: old_sound) 
     200Mar 24 12:27:02 <ajessu>        +1 
     201Mar 24 12:27:04 <srohweder>     0 
     202Mar 24 12:27:04 <lsmith>        -1 for .ini 
     203Mar 24 12:27:05 <beberlei>      +1 for ini 
     204Mar 24 12:27:06 <snc_hw>        but then my issue should be fixed 
     205Mar 24 12:27:06 <avalanche123>  +1 
     206Mar 24 12:27:09 <igorw> -1 for ini 
     207Mar 24 12:27:25 <snc_hw>        escape the "=" in the configurator 
     208Mar 24 12:27:30 <lsmith>        ok voting ending in 10 
     209Mar 24 12:27:39 <lsmith>        5 
     210Mar 24 12:27:53 <lsmith>        0 
     211Mar 24 12:27:56 <lsmith>        ok .. ini stays 
     212Mar 24 12:27:59 <lsmith>        next topic 
     213Mar 24 12:28:02 <lsmith>        "core" dev meeting in Paris: 
     214Mar 24 12:28:17 <lsmith>        basically i tried to remind us of our decisions from paris 
     215Mar 24 12:28:27 *       srohweder has quit (Quit: leaving) 
     216Mar 24 12:28:39 <lsmith>        i guess the "core bundle names" still need to be fixed 
     217Mar 24 12:28:45 <lsmith>        aka we wanted to also prefix them with Symfony 
     218Mar 24 12:28:50 *       ornicar has quit (Quit: WeeChat 0.3.4) 
     219Mar 24 12:28:56 <lsmith>        fabpot: i will open a ticket for this? 
     220Mar 24 12:29:27 <lsmith>        bridges have started to be created .. i guess each person responsible for a bundle/component can take care of that themselves? 
     221Mar 24 12:29:33 <fabpot>        lsmith: but the problem is that everything will be prefixed with symfony_ in config files 
     222Mar 24 12:29:49 <Seldaek>       fabpot: is this really a problem? 
     223Mar 24 12:29:53 <lsmith>        ok .. then lets discuss this 
     224Mar 24 12:29:55 <Seldaek>       it'll look weird for 3 days 
     225Mar 24 12:29:58 <Seldaek>       then we'll be used to it 
     226Mar 24 12:30:02 <jmikola|w>     wasn't kriswallsmith's aliases able to work around that? 
     227Mar 24 12:30:04 <lsmith>        i agree with Seldaek 
     228Mar 24 12:30:20 <jmikola|w>     or were we not going to employ that for the core config stuff 
     229Mar 24 12:30:36 *       Bastor ( has joined #symfony-dev 
     230Mar 24 12:30:37 <fabpot>        I don't see the big deal about keeping the current names for core bundles 
     231Mar 24 12:30:49 <lsmith>        fabpot: its about eating our own standards 
     232Mar 24 12:30:50 <henrikbjorn>   i think the current names should stay 
     233Mar 24 12:31:09 <fabpot>        lsmith: that's already not the case as we have a Bundle\ sub-namespace 
     234Mar 24 12:31:12 <lsmith>        or at least we then should state clearly in our docs that people shouldnt look at the core bundles if they want to follow our "best practices" 
     235Mar 24 12:31:14 <jmikola|w>     is essentially the same as using non-prefixed service id's elsewhere... if core stuff is going to have top-level names w/o prefixes for services, i don't see why not for configs 
     236Mar 24 12:31:15 <henrikbjorn>   lsmith: they are point zero and core to the framework so they dont really belong to anyone 
     237Mar 24 12:31:50 <jmikola|w>     lsmith: perhaps that best practice should start applying for something like FrameworkExtraBundle? instead of the core stuff 
     238Mar 24 12:32:02 <fabpot>        jmikola|w: that's already the case 
     239Mar 24 12:32:15 <lsmith>        alright then .. i will submit something a PR to add to the docs that core Bundles do not follow the best practices 
     240Mar 24 12:32:24 <jmikola|w>     yes; i meant to say that's the line when we start enforcing best practices, not core bundles 
     241Mar 24 12:32:26 <everzet>       :-) 
     242Mar 24 12:32:44 <lsmith>        so bridges each of the maintainers will handle themselves 
     243Mar 24 12:33:00 <lsmith>        missing interfaces should just be filed as tickets or PR's by the person that misses them 
     244Mar 24 12:33:29 <lsmith>        "overwriting bundle parameters" .. i will submit a PR to add to the docs that people shouldnt rely on BC when overriding bundle parameters 
     245Mar 24 12:33:43 <lsmith>        should i create a ticket for removing class parameters? 
     246Mar 24 12:34:03 <Seldaek>       I would say no 
     247Mar 24 12:34:09 *       DolbyDB (~IceChat77@ has joined #symfony-dev 
     248Mar 24 12:34:10 <fabpot>        lsmith: that's also on my TODO list 
     249Mar 24 12:34:14 <Seldaek>       they can stay there as an unsupported extension point for dirty hacks 
     250Mar 24 12:34:14 <lsmith>        k 
     251Mar 24 12:34:22 <Seldaek>       but nobody seems to like that :p 
     252Mar 24 12:34:41 <everzet>       Seldaek: no one likes dirty hacks anymore :-( 
     253Mar 24 12:34:51 <Seldaek>       yeah, that's just no fun. dirty hacks are useful sometimes. 
     254Mar 24 12:34:58 <lsmith>        ok .. that covers all the topics from that list that havent been covered yet 
     255Mar 24 12:35:04 <Seldaek>       everything is private and strict now.. 
     256Mar 24 12:35:05 <lsmith>        so next topic .. ok? 
     257Mar 24 12:35:07 <henrikbjorn>   looks like ill need to redefine a lot of services then 
     258Mar 24 12:35:08 <jmikola|w>     Seldaek: we still need dirty hacks for some things :) 
     259Mar 24 12:35:09 <henrikbjorn>   awesome 
     260Mar 24 12:35:13 <johanness>     actually changing the class is less risky than changing the entire service 
     261Mar 24 12:35:47 <lsmith>        Naming collisions with Bundles:, 
     262Mar 24 12:35:50 <lsmith>        kriswallsmith: ? 
     263Mar 24 12:35:54 <Seldaek>       yeah I really don't htink it's a good idea to remove those class params 
     264Mar 24 12:36:14 <everzet>       Seldaek: +1 
     265Mar 24 12:36:15 <kriswallsmith> i just stepped away, what's up? 
     266Mar 24 12:36:16 <beberlei>      regarding bridges, we will create a doctrine one for form related stuff and move some stuff for twig into the twig one 
     267Mar 24 12:36:16 *       jstout (~jstout@ has joined #symfony-dev 
     268Mar 24 12:36:21 *       dbu has quit (Remote host closed the connection) 
     269Mar 24 12:36:27 <fabpot>        beberlei: thanks 
     270Mar 24 12:36:33 <beberlei>      i had a question about naming bridges that combine two components 
     271Mar 24 12:36:51 <beberlei>      for example the translating helper in Framework Bundle 
     272Mar 24 12:36:54 <lsmith>        kriswallsmith: just wanted to move to the topic of bundle alias's .. but it seems we are not yet ready to 
     273Mar 24 12:37:09 *       jakubzalas ( has joined #symfony-dev 
     274Mar 24 12:37:11 <beberlei>      should we create a Symfony\Bridge\TemplatingTranslation ? 
     275Mar 24 12:37:16 <beberlei>      or how should that be handled 
     276Mar 24 12:37:19 <kriswallsmith> i think class names should remain as parameters 
     277Mar 24 12:37:45 <lsmith>        ok .. so does everybody understand the topic if class parameter removal? if so we can have a quick vote 
     278Mar 24 12:37:52 <jmikola|w>     kriswallsmith: perhaps at least for public services? or privates as well 
     279Mar 24 12:38:08 <fabpot>        beberlei: bridges are for third-party libraries only 
     280Mar 24 12:38:10 <henrikbjorn>   -1 for removing 
     281Mar 24 12:38:18 <fabpot>        -1 
     282Mar 24 12:38:21 <everzet>       -1 
     283Mar 24 12:38:21 <avalanche123>  -1 
     284Mar 24 12:38:30 <kriswallsmith> -1 for removing 
     285Mar 24 12:38:30 *       igorw_ ( has joined #symfony-dev 
     286Mar 24 12:38:31 *       igorw_ has quit (Changing host) 
     287Mar 24 12:38:31 *       igorw_ (~igorw@phpbb/developer/evil3) has joined #symfony-dev 
     288Mar 24 12:38:35 <Seldaek>       +1 for dirty hacks 
     289Mar 24 12:38:40 <kriswallsmith> heh 
     290Mar 24 12:38:41 <everzet>       Seldaek: :-D 
     291Mar 24 12:38:49 <beberlei>      fabpot: so how should we handle the translation helper? it seems to me that its wrongly placed in framework bundle 
     292Mar 24 12:38:51 <lsmith>        i know bschussek was -1 (aka removing) .. i am +0 
     293Mar 24 12:38:54 <jmikola|w>     -1, unless we go all out for configs that make it easier to avoid dirty hacks 
     294Mar 24 12:39:08 <lsmith>        kriswallsmith: are you sure you voted like you intended? 
     295Mar 24 12:39:08 <henrikbjorn>   to be honost a lot of flexibilty is gone if class params are removed 
     296Mar 24 12:39:20 <lsmith>        ah no 
     297Mar 24 12:39:23 <lsmith>        i am confused 
     298Mar 24 12:39:24 *       ornicar (~ornicar@ has joined #symfony-dev 
     299Mar 24 12:39:28 <beberlei>      i am against removal 
     300Mar 24 12:39:31 <fabpot>        beberlei: I will have a look at this specific example 
     301Mar 24 12:39:31 <beberlei>      if that is -1 
     302Mar 24 12:39:35 <lsmith>        so -1 is not removing the class parameters 
     303Mar 24 12:39:38 <fabpot>        yes 
     304Mar 24 12:39:40 <avalanche123>  yes 
     305Mar 24 12:39:41 <jmikola|w>     i thought it was 
     306Mar 24 12:39:42 *       johnwards ( has joined #symfony-dev 
     307Mar 24 12:39:44 <everzet>       yep 
     308Mar 24 12:39:46 <beberlei>      lol 
     309Mar 24 12:39:46 <fabpot>        so, basically nobody want to remove them 
     310Mar 24 12:39:48 <lsmith>        ok .. so they will stay .. 
     311Mar 24 12:39:50 <avalanche123>  yes 
     312Mar 24 12:39:54 <jmikola|w>     great success! 
     313Mar 24 12:39:55 <lsmith>        good 
     314Mar 24 12:39:58 <lsmith>        now moving on 
     315Mar 24 12:39:58 <henrikbjorn>   awesome 
     316Mar 24 12:39:59 <henrikbjorn>   :p 
     317Mar 24 12:40:00 <avalanche123>  unity 
     318Mar 24 12:40:01 <lsmith>        Naming collisions with Bundles:, 
     319Mar 24 12:40:02 *       igorw has quit (Ping timeout: 276 seconds) 
     320Mar 24 12:40:03 *       igorw_ is now known as igorw 
     321Mar 24 12:40:05 <lsmith>        kriswallsmith: take it away :) 
     322Mar 24 12:40:29 <lsmith>        or fabpot .. i saw you have made up your mind 
     323Mar 24 12:40:46 <lsmith>        or lets say the topic is many fold 
     324Mar 24 12:41:09 <lsmith>        i think one is about in general us not enforcing namespacing of services etc in Bundles 
     325Mar 24 12:41:20 <lsmith>        the other is kriswallsmith's PR about Bundle alias's 
     326Mar 24 12:41:22 *       kris|m ( has joined #symfony-dev 
     327Mar 24 12:41:58 <lsmith>        imho not enforcing namespacing for services and the likes is ok .. we just have to document it as part of the best practices 
     328Mar 24 12:42:17 <fabpot>        lsmith: I don't understand why we would want to enforce namespaces for services 
     329Mar 24 12:42:24 <lsmith>        fabpot: neither do i 
     330Mar 24 12:42:25 <beberlei>      hm, every implementator has the right to claim the default namespace for himself 
     331Mar 24 12:42:39 <beberlei>      so "request", "router" as a service is very nice imho 
     332Mar 24 12:42:54 <beberlei>      namespacing third party bundle services should be done though 
     333Mar 24 12:42:58 *       IfSixWasNine has quit (Quit: IfSixWasNine) 
     334Mar 24 12:42:59 <beberlei>      as a best practice 
     335Mar 24 12:43:06 <beberlei>      am i talking on the right topic? 
     336Mar 24 12:43:08 <beberlei>      :p 
     337Mar 24 12:43:12 <lsmith>        beberlei: yes .. by documentation .. not by force 
     338Mar 24 12:43:24 <lsmith>        so the other side of the topic is 
     339Mar 24 12:43:32 <lsmith>        aka "Bundle (and extension) aliases" 
     340Mar 24 12:43:39 <lsmith>        which is kriswallsmith's pull .. but he seems to be afk? 
     341Mar 24 12:44:04 *       kris|m has quit (Client Quit) 
     342Mar 24 12:44:15 <lsmith>        from fabpot's last comment .. it sounds like either we shouldnt add the feature at all 
     343Mar 24 12:44:21 <fabpot>        I'm -1 as it introduces yet another way to reference a bundle 
     344Mar 24 12:44:35 <kriswallsmith> I'm here 
     345Mar 24 12:44:46 <lsmith>        or at least only offer it as a "use at your own risk" for peoples own application bundles 
     346Mar 24 12:44:51 <Seldaek>       I think if it's merged, then the @-magic should go away so it's either FQCN, or alias 
     347Mar 24 12:45:06 <rande> me too ;) I will prefer to remove the 'Bundle' keyword 
     348Mar 24 12:45:12 <Seldaek>       but the fact that it's defined outside of the bundle is a bit nasty 
     349Mar 24 12:45:37 <kriswallsmith> Seldaek: that's the whole point 
     350Mar 24 12:45:49 <kriswallsmith> I'm ok with closing the PR 
     351Mar 24 12:45:59 <Seldaek>       of course, if we called Bundles "Zs" instead of Bundles, then it'd be easier to type BlogZ:Post:blah.html.twig 
     352Mar 24 12:46:00 *       henrikbjorn has quit (Ping timeout: 276 seconds) 
     353Mar 24 12:46:06 <fabpot>        rande: we can remove  
     354the Bundle suffix, that's a valid proposal 
     355Mar 24 12:46:07 <kriswallsmith> if people don't like it 
     356Mar 24 12:46:08 *       henrikbjorn ( has joined #symfony-dev 
     357Mar 24 12:46:10 <Seldaek>       +1s on Zs? :/ 
     358Mar 24 12:46:12 *       henrikbjorn has quit (Remote host closed the connection) 
     359Mar 24 12:46:27 <everzet>       fabpot: oh. That's interesting 
     360Mar 24 12:46:34 <Seldaek>       fabpot: seriously? I don't know how many times I've bitched about the Bundle suffix 
     361Mar 24 12:46:44 <Seldaek>       that'd be awesome 
     362Mar 24 12:46:49 <everzet>       Seldaek: +1 
     363Mar 24 12:46:52 <avalanche123>  Bundle\Bundle\BundleBundle 
     364Mar 24 12:47:19 <fabpot>        avalanche123: so, you work for the Bundle company now? that's a problem for sure ;) 
     365Mar 24 12:47:23 <Seldaek>       Symfony\Bundle\Framework\FrameworkBundle / Liip\View\ViewBundle 
     366Mar 24 12:47:24 <avalanche123>  :) 
     367Mar 24 12:47:35 <everzet>       Behat\Bundle\BehatBundle 
     368Mar 24 12:47:39 <avalanche123>  fabpot, indeed, we make Bundles 
     369Mar 24 12:47:40 <Seldaek>       that'd be nicer already, and especially View:Foo:bar would be much nicer 
     370Mar 24 12:47:45 <fabpot>        Liip\View\ViewBundle should be Liip\View\LiipViewBundle 
     371Mar 24 12:47:52 <Seldaek>       fabpot: yeah sorry 
     372Mar 24 12:47:56 <fabpot>        so LiipView:For:Bar 
     373Mar 24 12:47:57 <avalanche123>  oh 
     374Mar 24 12:48:02 <avalanche123>  so Bundle\Bundle\BundleBundleBundle 
     375Mar 24 12:48:09 <jstout>        avalanche123: haha 
     376Mar 24 12:48:42 <avalanche123>  :) 
     377Mar 24 12:48:43 <lsmith>        ok why didnt we change this before? 
     378Mar 24 12:48:50 <lsmith>        because i remember that we talked about it 
     379Mar 24 12:49:01 <avalanche123>  it wasn't that obvious I think 
     380Mar 24 12:49:05 <Seldaek>       afaik, everytime I ranted, it was said that it was confusing that the directory wasn't called *Bundle 
     381Mar 24 12:49:14 <avalanche123>  and it alse made sense, we have *Controller classes 
     382Mar 24 12:49:15 <everzet>       lsmith: because there was no Bundle\Bundle\BundleBundleBundle 
     383Mar 24 12:49:31 <Seldaek>       but on the other hand, it makes the code feel symfony specific because it is called bundle, while it's really not that specific 
     384Mar 24 12:49:36 <kriswallsmith> we can just lob Bundle off the name 
     385Mar 24 12:49:38 <Seldaek>       so it's better without *Bundle imo 
     386Mar 24 12:49:47 <Seldaek>       we might even argue we don't need bridges anymore ;) 
     387Mar 24 12:49:58 <kriswallsmith> no need to change the class name or ns 
     388Mar 24 12:49:59 <jmikola|w>     so Bundle only goes in the namespace component, or it's completely optional? i was also afk 
     389Mar 24 12:50:14 <fabpot>        Just to be clear, I propose to remove the Bundle suffix in the shortcut notation, I do not propose to rename the bundle class 
     390Mar 24 12:50:20 <everzet>       I think we don't need Bundle in actual bundle name as we already have it in NS 
     391Mar 24 12:50:23 <lsmith>        fabpot: ah :) 
     392Mar 24 12:50:27 <avalanche123>  fabpot understood that and +1 
     393Mar 24 12:50:30 <jmikola|w>     fabpot: that certainly makes sense 
     394Mar 24 12:50:30 <beberlei>      fabpot: +1 
     395Mar 24 12:50:34 <kriswallsmith> fabpot: +1 
     396Mar 24 12:50:36 <lsmith>        thats what i also understood initially .. but people confused me 
     397Mar 24 12:50:41 <Seldaek>       fabpot: ok, that's only 0.5x as awesome, but it's still a great change 
     398Mar 24 12:50:44 <Stof>  fabpot: +1 
     399Mar 24 12:50:48 <jstout>        fabpot: +1 ! 
     400Mar 24 12:50:48 <lsmith>        +1 
     401Mar 24 12:50:55 <everzet>       +0.5 
     402Mar 24 12:51:01 <fabpot>        ok, who wants to work on the patch? 
     403Mar 24 12:51:12 <johanness>     can there be conflicts if we remove this? 
     404Mar 24 12:51:24 <Seldaek>       no, bundle was mandatory afaik 
     405Mar 24 12:51:36 <jmikola|w>     beberlei: when we call getRepository with something like MainBundle:User and it translates to Vendor/MainBundle/Entity/User, is that magic inside doctrine bundle? 
     406Mar 24 12:51:38 <lsmith>        i volunteer Seldaek :) 
     407Mar 24 12:51:54 <Seldaek>       lsmith: well, I would, but I have beer waiting for me. I can try to do it this weekend though 
     408Mar 24 12:51:57 <jmikola|w>     johanness: i don't think there will be conflicts, as it's just removing "Bundle" suffix across the board 
     409Mar 24 12:52:01 <beberlei>      jmikola: yes, its called Entity Namespace Alias 
     410Mar 24 12:52:06 bantu Bastor beberlei BeryWork bobthecow bshafs  
     411Mar 24 12:52:12 <kriswallsmith> I'll do the patch 
     412Mar 24 12:52:13 <jmikola|w>     beberlei: and those are configured from the config mapping block? 
     413Mar 24 12:52:19 <lsmith>        ok .. then last topic 
     414Mar 24 12:52:20 <lsmith>        Cache warming:, 
     415Mar 24 12:52:23 <lsmith>        kriswallsmith: thx! 
     416Mar 24 12:52:23 <beberlei>      jmikola|w yes 
     417Mar 24 12:52:30 <lsmith>        is there still something to be done where? 
     418Mar 24 12:52:38 <lsmith>        s/where/there 
     419Mar 24 12:52:43 <Stof>  jmikola|w: Doctrine allows to define an alias for a namespace. Then DoctrineBundle define it by default for bundles and you can change them 
     420Mar 24 12:52:48 <Seldaek>       kriswallsmith: great 
     421Mar 24 12:52:59 <fabpot>        lsmith: yes, I have not had time to have a look at it 
     422Mar 24 12:53:03 *       chirimoya has quit (Quit: Linkinus - 
     423Mar 24 12:53:17 <beberlei>      Stof: you can change them, there is a parameter ofr it 
     424Mar 24 12:53:29 <beberlei>      was it removed? 
     425Mar 24 12:53:34 <lsmith>        is there someone else with sufficient deep understanding of all the issues that could discuss this with you fabpot to take it off your hands? 
     426Mar 24 12:53:35 <Stof>  beberlei: I just said it 
     427Mar 24 12:53:36 <kriswallsmith> beberlei: can you update D bundles with the alias change? 
     428Mar 24 12:53:40 *       tystr (~tylerstro@ has joined #symfony-dev 
     429Mar 24 12:53:51 <Seldaek>       just one quick question if we are out of topics.. what's with the form component? should we schedule a meeting this weekend? should we all try to have a look at it? Can someone do a PoC bundle we could look at to get a feel how it works? 
     430Mar 24 12:53:52 <fabpot>        lsmith: I just have a feeling, no hard facts 
     431Mar 24 12:53:53 <beberlei>      just remove the *BUndle or what? 
     432Mar 24 12:53:53 <Stof>  kriswallsmith: I will do that 
     433Mar 24 12:54:05 <kriswallsmith> Stof: thanks 
     434Mar 24 12:54:15 <kriswallsmith> beberlei: exactly 
     435Mar 24 12:54:35 <avalanche123>  I wanted to discuss mongodb session storage and where you think it makes sense to put it 
     436Mar 24 12:54:59 <avalanche123>  I have it implemented and working and we don't want to put it into http foundation 
     437Mar 24 12:55:05 <avalanche123>  but it doesn't rely on doctrine 
     438Mar 24 12:55:07 <beberlei>      bridge 
     439Mar 24 12:55:13 <avalanche123>  and uses raw Mongo class 
     440Mar 24 12:55:26 <avalanche123>  beberlei, how does it work? 
     441Mar 24 12:55:29 <jstout>        I'm with Saldaek on the forms. 
     442Mar 24 12:55:48 <johanness>     avalanche123, why don't you want to put it into http foundation? 
     443Mar 24 12:55:53 <fabpot>        beberlei: no, it's not a bridge as their is no third-party lib 
     444Mar 24 12:56:02 <fabpot>        johanness: because I don't want to 
     445Mar 24 12:56:02 <lsmith>        beberlei: so the PR didnt happen today .. will it happen tomorrow? 
     446Mar 24 12:56:04 <beberlei>      pecl/mongodb is sort of third party :D 
     447Mar 24 12:56:06 <johanness>     :) 
     448Mar 24 12:56:07 <jmikola|w>     avalanche123: is there a memcache driver in core? 
     449Mar 24 12:56:18 <avalanche123>  jmikola|w, not necessary 
     450Mar 24 12:56:24 <beberlei>      lsmith: bschussek will be back at 9, there are small details that need to be worked on, the PR will be tonight or tomorrow 
     451Mar 24 12:56:30 <lsmith>        ok 
     452Mar 24 12:56:30 <avalanche123>  you just configure memcache with session support when compiling php 
     453Mar 24 12:56:36 <avalanche123>  jmikola|w ^ 
     454Mar 24 12:56:37 <mvrhov>        regarding the experimental forms. Rendering is broken currently so I've converted one form class to new syntax, but got stuck there. 
     455Mar 24 12:56:40 <lsmith>        so i think we need at least 24 hours to review the PR 
     456Mar 24 12:56:47 <lsmith>        before it makes sense to take a decision 
     457Mar 24 12:56:48 <Seldaek>       jmikola|w: it's not about core/thirdparty, it's about what we want to support in Sf-core I think 
     458Mar 24 12:56:52 *       guilhermeblanco (~quassel@nat/yahoo/x-hoarhdgilokaksdg) has joined #symfony-dev 
     459Mar 24 12:57:05 <lsmith>        should we do an IRC meeting to discuss the last questions and vote on the weekend? 
     460Mar 24 12:57:07 <avalanche123>  Seldaek right 
     461Mar 24 12:57:09 <beberlei>      there will also be an Acme Bundle on the Forms 
     462Mar 24 12:57:18 <lsmith>        beberlei: great 
     463Mar 24 12:57:23 <beberlei>      so that everyone can see some use.cases, i am working on that tonight 
     464Mar 24 12:57:28 <fabpot>        lsmith: I will definitely need more than 24 hours 
     465Mar 24 12:57:31 <avalanche123>  so beberlei, HttpFoundationMongoBridge? 
     466Mar 24 12:57:35 <jmikola|w>     Seldaek: i was just considering if there was a problem conditionally supporting pecl extensions in core 
     467Mar 24 12:57:42 <lsmith>        ok .. so then a meetin on monday? 
     468Mar 24 12:57:46 <Seldaek>       jmikola|w: the question is, if we move it in core, can we trust avalanche123 to maintain it or will he try to make a run for the mexican border at the first occasion? 
     469Mar 24 12:57:46 <lsmith>        or wait until next thursday 
     470Mar 24 12:58:04 <jmikola|w>     Seldaek: Mongo doesn't really seem common enough to be in core, but i don't see harm in having the code there - it simply wouldn't get loaded if people don't use it 
     471Mar 24 12:58:05 <lsmith>        or only schedule a meeting if we feel we need one 
     472Mar 24 12:58:20 <lsmith>        otherwise just handle it via PR comments and mailinglist 
     473Mar 24 12:58:22 <jmikola|w>     Seldaek: Bulat legally can't cross any other borders, so we're good 
     474Mar 24 12:58:27 <avalanche123>  Seldaek, you can trust me ;) 
     475Mar 24 12:58:31 <fabpot>        lsmith: yes, let's discuss everything on the ML 
     476Mar 24 12:58:35 <lsmith>        ok 
     477Mar 24 12:58:38 <avalanche123>  jmikola|w haha 
     478Mar 24 12:58:40 *       henrikbjorn ( has joined #symfony-dev 
     479Mar 24 12:58:41 <lsmith>        so then meeting done