Response sub-classes vs. exceptions for HTTP status codes
Review: Services naming
Whats missing for RC1?
"core" dev meeting in Paris
Naming collisions with Bundles
mongodb session storage
Mar 24 12:00:46 <lsmith> so lets go
Mar 24 12:01:09 <lsmith> Response sub-classes vs. exceptions for HTTP status codes: http://bit.ly/eeo28C
Mar 24 12:01:12 <lsmith> fabpot: ping
Mar 24 12:01:18 <lsmith> kriswallsmith: ping
Mar 24 12:01:23 <fabpot> pong
Mar 24 12:01:27 <kriswallsmith> pong
Mar 24 12:01:30 <beberlei> oink
Mar 24 12:01:48 <lsmith> i guess both fabpot and kriswallsmith now think we shouldnt do this
Mar 24 12:01:58 <kriswallsmith> yes, it takes control away from the user
Mar 24 12:02:04 <fabpot> I created the 2 pull requests because I was not sure
Mar 24 12:02:05 <lsmith> leaving me (and maybe Seldaek) who also think we should do this
Mar 24 12:02:25 * johnkary (~email@example.com) has joined #symfony-dev
Mar 24 12:02:29 <fabpot> I think this is more a documentation problem, than a technical one
Mar 24 12:02:33 <lsmith> kriswallsmith: well we direct things to a central place by default
Mar 24 12:02:46 <jmikola|w> is the argument against using sub-classes?
Mar 24 12:02:54 <jmikola|w> i see nothing in the ML link other than Jordi's +1
Mar 24 12:03:03 <Seldaek> jmikola|w: it's in the PR
Mar 24 12:03:08 <fabpot> jmikola|w: everything is in the PRs
Mar 24 12:03:08 <kriswallsmith> the centralized solution is there unless the user opts out of it by returning a response
Mar 24 12:03:25 <kriswallsmith> so, +1 for addressing in documentation
Mar 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
Mar 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
Mar 24 12:04:16 <lsmith> johanness: ping
Mar 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
Mar 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
Mar 24 12:05:11 <lsmith> johanness: well its not that we dont want them to do that
Mar 24 12:05:14 <fabpot> johanness: that's what my PR does
Mar 24 12:05:17 <lsmith> its just that we want to prevent surprises
Mar 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
Mar 24 12:05:29 <lsmith> but i can live with it being handled by documentation ..
Mar 24 12:05:39 <lsmith> though i think we could just as well document how to undo the default
Mar 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
Mar 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
Mar 24 12:06:06 <lsmith> but i guess the PR handles hiding a user error while forcing advanced users to change defaults
Mar 24 12:06:17 <Seldaek> kriswallsmith: yeah that's definitely true, the current way (pre-PR) is at least straightforward
Mar 24 12:06:27 <kriswallsmith> i don't think that level of strictness is necessary johanness
Mar 24 12:06:54 <johanness> kriswallsmith, but we want users to do that
Mar 24 12:07:07 <johanness> why should we put that into the documentation otherwise?
Mar 24 12:07:07 <lsmith> johanness: the question is do we?
Mar 24 12:07:11 <kriswallsmith> it doesn't matter if they throw an exception or a response, it's up to them
Mar 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?
Mar 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
Mar 24 12:07:38 <lsmith> since most likely you dont want it triggered there
Mar 24 12:07:56 <kriswallsmith> we shouldn't for a user into more abstraction
Mar 24 12:08:01 * bschussek has quit (Quit: May the force be with you)
Mar 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
Mar 24 12:08:24 <lsmith> we should also not just focus on this aspect ..
Mar 24 12:08:25 <lsmith> http://www.google.com/url?sa=D&q=https://github.com/symfony/symfony/pull/369
Mar 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
Mar 24 12:08:50 <lsmith> pull 370 is fairly clear cut .. you either favor one or the other
Mar 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
Mar 24 12:08:58 <lsmith> PR 369 is a bit trickier from my POV
Mar 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
Mar 24 12:09:53 <fabpot> jmikola|w: read my post on the ML, everything is explained there
Mar 24 12:10:46 <lsmith> johanness/fabpot: did you find a common ground on PR 369?
Mar 24 12:10:51 <lsmith> and if so .. what is it?
Mar 24 12:11:02 * kertz has quit (Ping timeout: 240 seconds)
Mar 24 12:11:09 <jmikola|w> fabpot: yes, i see the list of what exceptions you're choosing to implement
Mar 24 12:11:10 <fabpot> lsmith: not yet
Mar 24 12:11:19 <johanness> we first need to settle on a general strategy imo
Mar 24 12:11:23 <lsmith> ok
Mar 24 12:11:47 <kriswallsmith> should be be concerned that http exceptions can be thrown from anywhere in the application?
Mar 24 12:11:54 <kriswallsmith> i.e. from the model?
Mar 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?
Mar 24 12:12:07 * henrikbjorn (~Henrik@18.104.22.168.generic-hostname.arrownet.dk) has joined #symfony-dev
Mar 24 12:12:19 <johanness> lsmith, what does "solve this by documentation" mean?
Mar 24 12:12:26 <kriswallsmith> is this a community decision?
Mar 24 12:12:42 <lsmith> johanness: document that if you want the exception listener triggerd .. throw an exception
Mar 24 12:12:51 <lsmith> if you dont ... return a response
Mar 24 12:13:02 * M00nShield has quit (Ping timeout: 240 seconds)
Mar 24 12:13:30 <iAsterisk> why should response go through an exception listener?
Mar 24 12:13:43 <fabpot> ok, let's stop this discussion, it's going nowhere
Mar 24 12:14:00 <iAsterisk> from the outside it looks confusing.
Mar 24 12:14:04 <fabpot> I'm going to close PR 370 and let things as they are now
Mar 24 12:14:05 <lsmith> yes .. thats why i was asking for a vote
Mar 24 12:14:10 <lsmith> ok
Mar 24 12:14:11 <kriswallsmith> sounds good, let's move on
Mar 24 12:14:24 <lsmith> what about PR 369?
Mar 24 12:14:31 <lsmith> anything we can discuss here to move things along?
Mar 24 12:15:07 <lsmith> ok .. since nobody is speaking up
Mar 24 12:15:09 <lsmith> next topic
Mar 24 12:15:11 <lsmith> Review: Services naming: http://bit.ly/hfvVK8
Mar 24 12:15:17 <kriswallsmith> i'm still recusing myself from all security stuff
Mar 24 12:16:10 <lsmith> i guess here the main question is if anyone is willing to spear head this?
Mar 24 12:16:20 <lsmith> aka look through the list that jordi generated
Mar 24 12:16:22 <Seldaek> yeha, I did my part with the grepping :p
Mar 24 12:16:31 <henrikbjorn> define the naming, wasnt it about making some of them less verbose ?
Mar 24 12:16:32 <lsmith> and try to find common naming patterns
Mar 24 12:16:35 <lsmith> maybe document them
Mar 24 12:16:36 <fabpot> lsmith: I will do that, it's on my todo list already
Mar 24 12:16:43 <lsmith> ok
Mar 24 12:16:49 <lsmith> then there is nothing to discuss there either?
Mar 24 12:16:49 <everzet> cool
Mar 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
Mar 24 12:17:09 * DrRotmos (~firstname.lastname@example.org) has joined #symfony-dev
Mar 24 12:17:18 <lsmith> then moving on ..
Mar 24 12:17:24 <kriswallsmith> re: doctrine.odm.mongodb.default_document_manager, should we create a persistence manager-manager?
Mar 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
Mar 24 12:17:47 <everzet> Seldaek: +1
Mar 24 12:17:49 <Seldaek> 'cause I've seen lots of horrible things done in bundles by random people
Mar 24 12:17:50 <fabpot> Seldaek: I will try to find some naming conventions for sure
Mar 24 12:17:52 * kertz (~email@example.com) has joined #symfony-dev
Mar 24 12:18:02 <lsmith> next topic then: Whats missing for RC1?
Mar 24 12:18:11 <lsmith> not sure if anything has changed since last week really
Mar 24 12:18:16 <henrikbjorn> kriswallsmith: would be nice, but confusing if you use odm and orm at the same time
Mar 24 12:18:17 <Seldaek> forms, but nvm :)
Mar 24 12:18:22 <kriswallsmith> i think all public services should use only _ no .
Mar 24 12:18:38 <Seldaek> kriswallsmith: ah weird, I liked the dots
Mar 24 12:18:55 <Seldaek> I think they denote nesting much better than underscores
Mar 24 12:18:56 <fabpot> I have converted many components to private usage
Mar 24 12:18:56 <jmikola|w> kriswallsmith: dots are helpful for namespacing
Mar 24 12:18:57 <everzet> kriswallsmith: dots is better
Mar 24 12:19:06 <everzet> kriswallsmith: *ARE better
Mar 24 12:19:11 <fabpot> but some still need to be done: Serializer, Form, and Validation
Mar 24 12:19:20 <kriswallsmith> we should have very few public services
Mar 24 12:19:22 <Seldaek> aye, it's on my todo
Mar 24 12:20:05 <Seldaek> kriswallsmith: still, it just feels more natural to use <some_ns>.<name>, looks like twig variables
Mar 24 12:20:08 <henrikbjorn> private = cant be changed or ?
Mar 24 12:20:11 <lsmith> anything else that has changed since last week in terms of getting to RC1?
Mar 24 12:20:21 <lsmith> fabpot: one question .. so the next release will be called beta1?
Mar 24 12:20:23 <lsmith> or RC1?
Mar 24 12:20:25 <Stof> henrikbjorn: can't be retrieved at runtime
Mar 24 12:20:31 <henrikbjorn> ok
Mar 24 12:20:34 <lsmith> and if beta1 .. will we also have an RC phase?
Mar 24 12:20:38 * mapi_ has quit (Ping timeout: 255 seconds)
Mar 24 12:20:40 <everzet> lsmith: RC without beta's is quite extreme :-)
Mar 24 12:20:42 <fabpot> lsmith: beta1 as we won't have the service renames for instance
Mar 24 12:20:43 <lsmith> just because i have seen some people wondering
Mar 24 12:20:51 <lsmith> ok
Mar 24 12:20:54 <everzet> lsmith: but i think our current PR's is already beta's
Mar 24 12:20:55 <fabpot> some betas and then some RCs
Mar 24 12:21:19 <lsmith> ok .. then moving on to the next topic -> why parameters.ini? http://bit.ly/ghx4dx
Mar 24 12:21:21 <fabpot> everzet: beta means that all features are there but with bugs ;)
Mar 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
Mar 24 12:21:45 <Seldaek> because we are all up to speed here, but the users at large aren't
Mar 24 12:21:45 <everzet> fabpot: it's strange, but i was always thought it is RC :-D
Mar 24 12:22:04 <fabpot> everzet: RC means that we won't break BC
Mar 24 12:22:14 * nostrzak (~firstname.lastname@example.org) has joined #symfony-dev
Mar 24 12:22:21 <lsmith> fabpot: basically many of us have been wondering why the SE uses ini format
Mar 24 12:22:24 <fabpot> Seldaek: right, I will do that when announcing the beta1 next week
Mar 24 12:22:32 <lsmith> what is the motivation for this?
Mar 24 12:22:34 <Seldaek> ok cool
Mar 24 12:22:43 <lsmith> given the flexibility of ini parsing in php 5.3 ..
Mar 24 12:22:48 <everzet> fabpot: :-D Ok. It's just me. I've thought that beta is just betta than nothing...
Mar 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
Mar 24 12:22:50 * rouffj (~email@example.com) has joined #symfony-dev
Mar 24 12:22:52 <lsmith> i dont really see much difference between ini and yaml
Mar 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
Mar 24 12:23:34 <Stof> then do all config in ini, not just one of the files :)
Mar 24 12:23:40 <lsmith> well and what about the people that dont like ini for app config?
Mar 24 12:23:57 <henrikbjorn> well they can see all formats
Mar 24 12:24:04 <henrikbjorn> so they know they can choose whatever they want
Mar 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
Mar 24 12:24:18 <lsmith> i think adding a 4th format is adding confusion
Mar 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
Mar 24 12:24:29 <everzet> lsmith: but if you don't (very begginer) - ini is a good starting point
Mar 24 12:25:02 <everzet> lsmith: i think it's not about 4th format. It's about single configuration file for beginners.
Mar 24 12:25:06 <pgodel_work> an explanation would aid in avoiding confusion
Mar 24 12:25:32 <lsmith> i think our flexibility with formats is a plus
Mar 24 12:25:33 <srohweder> thfo the beginners you can include one yml and hide the complicated stuff in imports
Mar 24 12:25:38 <Seldaek> I guess the ini file is ok for standard distro maybe, but shouldn't be there in the others
Mar 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
Mar 24 12:25:43 <lsmith> but at the same time its confusing as hell for beginners already
Mar 24 12:25:44 <ajessu> just to get started
Mar 24 12:26:11 <lsmith> sure an ini file is something they will have seen with their php.ini
Mar 24 12:26:12 <pgodel_work> but it is confusing because there is no explanantion and it was a suprise for us
Mar 24 12:26:24 <Seldaek> on the other hand, all the sf1 users are used to yaml..
Mar 24 12:26:31 <everzet> lsmith: yeah. We need to tell them not to open other *.yml stuff before they'll become mature
Mar 24 12:26:33 <pgodel_work> but I think it is easily addressable by documeting properly
Mar 24 12:26:34 <lsmith> anyway ..
Mar 24 12:26:42 <lsmith> either we vote on it .. or let fabpot decide
Mar 24 12:26:46 <lsmith> no reason to keep talking about this
Mar 24 12:26:47 <henrikbjorn> +1
Mar 24 12:26:51 <everzet> +1
Mar 24 12:26:51 <henrikbjorn> for ini
Mar 24 12:27:00 <fabpot> +1
Mar 24 12:27:01 * old_sound has quit (Quit: old_sound)
Mar 24 12:27:02 <ajessu> +1
Mar 24 12:27:04 <srohweder> 0
Mar 24 12:27:04 <lsmith> -1 for .ini
Mar 24 12:27:05 <beberlei> +1 for ini
Mar 24 12:27:06 <snc_hw> but then my issue should be fixed
Mar 24 12:27:06 <avalanche123> +1
Mar 24 12:27:09 <igorw> -1 for ini
Mar 24 12:27:25 <snc_hw> escape the "=" in the configurator
Mar 24 12:27:30 <lsmith> ok voting ending in 10
Mar 24 12:27:39 <lsmith> 5
Mar 24 12:27:53 <lsmith> 0
Mar 24 12:27:56 <lsmith> ok .. ini stays
Mar 24 12:27:59 <lsmith> next topic
Mar 24 12:28:02 <lsmith> "core" dev meeting in Paris: http://bit.ly/ijZxVR
Mar 24 12:28:17 <lsmith> basically i tried to remind us of our decisions from paris
Mar 24 12:28:27 * srohweder has quit (Quit: leaving)
Mar 24 12:28:39 <lsmith> i guess the "core bundle names" still need to be fixed
Mar 24 12:28:45 <lsmith> aka we wanted to also prefix them with Symfony
Mar 24 12:28:50 * ornicar has quit (Quit: WeeChat 0.3.4)
Mar 24 12:28:56 <lsmith> fabpot: i will open a ticket for this?
Mar 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?
Mar 24 12:29:33 <fabpot> lsmith: but the problem is that everything will be prefixed with symfony_ in config files
Mar 24 12:29:49 <Seldaek> fabpot: is this really a problem?
Mar 24 12:29:53 <lsmith> ok .. then lets discuss this
Mar 24 12:29:55 <Seldaek> it'll look weird for 3 days
Mar 24 12:29:58 <Seldaek> then we'll be used to it
Mar 24 12:30:02 <jmikola|w> wasn't kriswallsmith's aliases able to work around that?
Mar 24 12:30:04 <lsmith> i agree with Seldaek
Mar 24 12:30:20 <jmikola|w> or were we not going to employ that for the core config stuff
Mar 24 12:30:36 * Bastor (~Babar@cie44-1-88-188-188-45.fbx.proxad.net) has joined #symfony-dev
Mar 24 12:30:37 <fabpot> I don't see the big deal about keeping the current names for core bundles
Mar 24 12:30:49 <lsmith> fabpot: its about eating our own standards
Mar 24 12:30:50 <henrikbjorn> i think the current names should stay
Mar 24 12:31:09 <fabpot> lsmith: that's already not the case as we have a Bundle\ sub-namespace
Mar 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"
Mar 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
Mar 24 12:31:15 <henrikbjorn> lsmith: they are point zero and core to the framework so they dont really belong to anyone
Mar 24 12:31:50 <jmikola|w> lsmith: perhaps that best practice should start applying for something like FrameworkExtraBundle? instead of the core stuff
Mar 24 12:32:02 <fabpot> jmikola|w: that's already the case
Mar 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
Mar 24 12:32:24 <jmikola|w> yes; i meant to say that's the line when we start enforcing best practices, not core bundles
Mar 24 12:32:26 <everzet> :-)
Mar 24 12:32:44 <lsmith> so bridges each of the maintainers will handle themselves
Mar 24 12:33:00 <lsmith> missing interfaces should just be filed as tickets or PR's by the person that misses them
Mar 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
Mar 24 12:33:43 <lsmith> should i create a ticket for removing class parameters?
Mar 24 12:34:03 <Seldaek> I would say no
Mar 24 12:34:09 * DolbyDB (~IceChat77@22.214.171.124) has joined #symfony-dev
Mar 24 12:34:10 <fabpot> lsmith: that's also on my TODO list
Mar 24 12:34:14 <Seldaek> they can stay there as an unsupported extension point for dirty hacks
Mar 24 12:34:14 <lsmith> k
Mar 24 12:34:22 <Seldaek> but nobody seems to like that :p
Mar 24 12:34:41 <everzet> Seldaek: no one likes dirty hacks anymore :-(
Mar 24 12:34:51 <Seldaek> yeah, that's just no fun. dirty hacks are useful sometimes.
Mar 24 12:34:58 <lsmith> ok .. that covers all the topics from that list that havent been covered yet
Mar 24 12:35:04 <Seldaek> everything is private and strict now..
Mar 24 12:35:05 <lsmith> so next topic .. ok?
Mar 24 12:35:07 <henrikbjorn> looks like ill need to redefine a lot of services then
Mar 24 12:35:08 <jmikola|w> Seldaek: we still need dirty hacks for some things :)
Mar 24 12:35:09 <henrikbjorn> awesome
Mar 24 12:35:13 <johanness> actually changing the class is less risky than changing the entire service
Mar 24 12:35:47 <lsmith> Naming collisions with Bundles: http://bit.ly/hwgDTp, http://bit.ly/hdCVYX
Mar 24 12:35:50 <lsmith> kriswallsmith: ?
Mar 24 12:35:54 <Seldaek> yeah I really don't htink it's a good idea to remove those class params
Mar 24 12:36:14 <everzet> Seldaek: +1
Mar 24 12:36:15 <kriswallsmith> i just stepped away, what's up?
Mar 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
Mar 24 12:36:16 * jstout (~firstname.lastname@example.org) has joined #symfony-dev
Mar 24 12:36:21 * dbu has quit (Remote host closed the connection)
Mar 24 12:36:27 <fabpot> beberlei: thanks
Mar 24 12:36:33 <beberlei> i had a question about naming bridges that combine two components
Mar 24 12:36:51 <beberlei> for example the translating helper in Framework Bundle
Mar 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
Mar 24 12:37:09 * jakubzalas (~email@example.com) has joined #symfony-dev
Mar 24 12:37:11 <beberlei> should we create a Symfony\Bridge\TemplatingTranslation ?
Mar 24 12:37:16 <beberlei> or how should that be handled
Mar 24 12:37:19 <kriswallsmith> i think class names should remain as parameters
Mar 24 12:37:45 <lsmith> ok .. so does everybody understand the topic if class parameter removal? if so we can have a quick vote
Mar 24 12:37:52 <jmikola|w> kriswallsmith: perhaps at least for public services? or privates as well
Mar 24 12:38:08 <fabpot> beberlei: bridges are for third-party libraries only
Mar 24 12:38:10 <henrikbjorn> -1 for removing
Mar 24 12:38:18 <fabpot> -1
Mar 24 12:38:21 <everzet> -1
Mar 24 12:38:21 <avalanche123> -1
Mar 24 12:38:30 <kriswallsmith> -1 for removing
Mar 24 12:38:30 * igorw_ (~firstname.lastname@example.org) has joined #symfony-dev
Mar 24 12:38:31 * igorw_ has quit (Changing host)
Mar 24 12:38:31 * igorw_ (~igorw@phpbb/developer/evil3) has joined #symfony-dev
Mar 24 12:38:35 <Seldaek> +1 for dirty hacks
Mar 24 12:38:40 <kriswallsmith> heh
Mar 24 12:38:41 <everzet> Seldaek: :-D
Mar 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
Mar 24 12:38:51 <lsmith> i know bschussek was -1 (aka removing) .. i am +0
Mar 24 12:38:54 <jmikola|w> -1, unless we go all out for configs that make it easier to avoid dirty hacks
Mar 24 12:39:08 <lsmith> kriswallsmith: are you sure you voted like you intended?
Mar 24 12:39:08 <henrikbjorn> to be honost a lot of flexibilty is gone if class params are removed
Mar 24 12:39:20 <lsmith> ah no
Mar 24 12:39:23 <lsmith> i am confused
Mar 24 12:39:24 * ornicar (~email@example.com) has joined #symfony-dev
Mar 24 12:39:28 <beberlei> i am against removal
Mar 24 12:39:31 <fabpot> beberlei: I will have a look at this specific example
Mar 24 12:39:31 <beberlei> if that is -1
Mar 24 12:39:35 <lsmith> so -1 is not removing the class parameters
Mar 24 12:39:38 <fabpot> yes
Mar 24 12:39:40 <avalanche123> yes
Mar 24 12:39:41 <jmikola|w> i thought it was
Mar 24 12:39:42 * johnwards (~firstname.lastname@example.org) has joined #symfony-dev
Mar 24 12:39:44 <everzet> yep
Mar 24 12:39:46 <beberlei> lol
Mar 24 12:39:46 <fabpot> so, basically nobody want to remove them
Mar 24 12:39:48 <lsmith> ok .. so they will stay ..
Mar 24 12:39:50 <avalanche123> yes
Mar 24 12:39:54 <jmikola|w> great success!
Mar 24 12:39:55 <lsmith> good
Mar 24 12:39:58 <lsmith> now moving on
Mar 24 12:39:58 <henrikbjorn> awesome
Mar 24 12:39:59 <henrikbjorn> :p
Mar 24 12:40:00 <avalanche123> unity
Mar 24 12:40:01 <lsmith> Naming collisions with Bundles: http://bit.ly/hwgDTp, http://bit.ly/hdCVYX
Mar 24 12:40:02 * igorw has quit (Ping timeout: 276 seconds)
Mar 24 12:40:03 * igorw_ is now known as igorw
Mar 24 12:40:05 <lsmith> kriswallsmith: take it away :)
Mar 24 12:40:29 <lsmith> or fabpot .. i saw you have made up your mind
Mar 24 12:40:46 <lsmith> or lets say the topic is many fold
Mar 24 12:41:09 <lsmith> i think one is about in general us not enforcing namespacing of services etc in Bundles
Mar 24 12:41:20 <lsmith> the other is kriswallsmith's PR about Bundle alias's
Mar 24 12:41:22 * kris|m (~email@example.com) has joined #symfony-dev
Mar 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
Mar 24 12:42:17 <fabpot> lsmith: I don't understand why we would want to enforce namespaces for services
Mar 24 12:42:24 <lsmith> fabpot: neither do i
Mar 24 12:42:25 <beberlei> hm, every implementator has the right to claim the default namespace for himself
Mar 24 12:42:39 <beberlei> so "request", "router" as a service is very nice imho
Mar 24 12:42:54 <beberlei> namespacing third party bundle services should be done though
Mar 24 12:42:58 * IfSixWasNine has quit (Quit: IfSixWasNine)
Mar 24 12:42:59 <beberlei> as a best practice
Mar 24 12:43:06 <beberlei> am i talking on the right topic?
Mar 24 12:43:08 <beberlei> :p
Mar 24 12:43:12 <lsmith> beberlei: yes .. by documentation .. not by force
Mar 24 12:43:24 <lsmith> so the other side of the topic is https://github.com/symfony/symfony/pull/186
Mar 24 12:43:32 <lsmith> aka "Bundle (and extension) aliases"
Mar 24 12:43:39 <lsmith> which is kriswallsmith's pull .. but he seems to be afk?
Mar 24 12:44:04 * kris|m has quit (Client Quit)
Mar 24 12:44:15 <lsmith> from fabpot's last comment .. it sounds like either we shouldnt add the feature at all
Mar 24 12:44:21 <fabpot> I'm -1 as it introduces yet another way to reference a bundle
Mar 24 12:44:35 <kriswallsmith> I'm here
Mar 24 12:44:46 <lsmith> or at least only offer it as a "use at your own risk" for peoples own application bundles
Mar 24 12:44:51 <Seldaek> I think if it's merged, then the @-magic should go away so it's either FQCN, or alias
Mar 24 12:45:06 <rande> me too ;) I will prefer to remove the 'Bundle' keyword
Mar 24 12:45:12 <Seldaek> but the fact that it's defined outside of the bundle is a bit nasty
Mar 24 12:45:37 <kriswallsmith> Seldaek: that's the whole point
Mar 24 12:45:49 <kriswallsmith> I'm ok with closing the PR
Mar 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
Mar 24 12:46:00 * henrikbjorn has quit (Ping timeout: 276 seconds)
Mar 24 12:46:06 <fabpot> rande: we can remove
the Bundle suffix, that's a valid proposal
Mar 24 12:46:07 <kriswallsmith> if people don't like it
Mar 24 12:46:08 * henrikbjorn (~Henrik@126.96.36.199.generic-hostname.arrownet.dk) has joined #symfony-dev
Mar 24 12:46:10 <Seldaek> +1s on Zs? :/
Mar 24 12:46:12 * henrikbjorn has quit (Remote host closed the connection)
Mar 24 12:46:27 <everzet> fabpot: oh. That's interesting
Mar 24 12:46:34 <Seldaek> fabpot: seriously? I don't know how many times I've bitched about the Bundle suffix
Mar 24 12:46:44 <Seldaek> that'd be awesome
Mar 24 12:46:49 <everzet> Seldaek: +1
Mar 24 12:46:52 <avalanche123> Bundle\Bundle\BundleBundle
Mar 24 12:47:19 <fabpot> avalanche123: so, you work for the Bundle company now? that's a problem for sure ;)
Mar 24 12:47:23 <Seldaek> Symfony\Bundle\Framework\FrameworkBundle / Liip\View\ViewBundle
Mar 24 12:47:24 <avalanche123> :)
Mar 24 12:47:35 <everzet> Behat\Bundle\BehatBundle
Mar 24 12:47:39 <avalanche123> fabpot, indeed, we make Bundles
Mar 24 12:47:40 <Seldaek> that'd be nicer already, and especially View:Foo:bar would be much nicer
Mar 24 12:47:45 <fabpot> Liip\View\ViewBundle should be Liip\View\LiipViewBundle
Mar 24 12:47:52 <Seldaek> fabpot: yeah sorry
Mar 24 12:47:56 <fabpot> so LiipView:For:Bar
Mar 24 12:47:57 <avalanche123> oh
Mar 24 12:48:02 <avalanche123> so Bundle\Bundle\BundleBundleBundle
Mar 24 12:48:09 <jstout> avalanche123: haha
Mar 24 12:48:42 <avalanche123> :)
Mar 24 12:48:43 <lsmith> ok why didnt we change this before?
Mar 24 12:48:50 <lsmith> because i remember that we talked about it
Mar 24 12:49:01 <avalanche123> it wasn't that obvious I think
Mar 24 12:49:05 <Seldaek> afaik, everytime I ranted, it was said that it was confusing that the directory wasn't called *Bundle
Mar 24 12:49:14 <avalanche123> and it alse made sense, we have *Controller classes
Mar 24 12:49:15 <everzet> lsmith: because there was no Bundle\Bundle\BundleBundleBundle
Mar 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
Mar 24 12:49:36 <kriswallsmith> we can just lob Bundle off the name
Mar 24 12:49:38 <Seldaek> so it's better without *Bundle imo
Mar 24 12:49:47 <Seldaek> we might even argue we don't need bridges anymore ;)
Mar 24 12:49:58 <kriswallsmith> no need to change the class name or ns
Mar 24 12:49:59 <jmikola|w> so Bundle only goes in the namespace component, or it's completely optional? i was also afk
Mar 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
Mar 24 12:50:20 <everzet> I think we don't need Bundle in actual bundle name as we already have it in NS
Mar 24 12:50:23 <lsmith> fabpot: ah :)
Mar 24 12:50:27 <avalanche123> fabpot understood that and +1
Mar 24 12:50:30 <jmikola|w> fabpot: that certainly makes sense
Mar 24 12:50:30 <beberlei> fabpot: +1
Mar 24 12:50:34 <kriswallsmith> fabpot: +1
Mar 24 12:50:36 <lsmith> thats what i also understood initially .. but people confused me
Mar 24 12:50:41 <Seldaek> fabpot: ok, that's only 0.5x as awesome, but it's still a great change
Mar 24 12:50:44 <Stof> fabpot: +1
Mar 24 12:50:48 <jstout> fabpot: +1 !
Mar 24 12:50:48 <lsmith> +1
Mar 24 12:50:55 <everzet> +0.5
Mar 24 12:51:01 <fabpot> ok, who wants to work on the patch?
Mar 24 12:51:12 <johanness> can there be conflicts if we remove this?
Mar 24 12:51:24 <Seldaek> no, bundle was mandatory afaik
Mar 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?
Mar 24 12:51:38 <lsmith> i volunteer Seldaek :)
Mar 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
Mar 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
Mar 24 12:52:01 <beberlei> jmikola: yes, its called Entity Namespace Alias
Mar 24 12:52:06 bantu Bastor beberlei BeryWork bobthecow bshafs
Mar 24 12:52:12 <kriswallsmith> I'll do the patch
Mar 24 12:52:13 <jmikola|w> beberlei: and those are configured from the config mapping block?
Mar 24 12:52:19 <lsmith> ok .. then last topic
Mar 24 12:52:20 <lsmith> Cache warming: http://bit.ly/dIoSCc, http://bit.ly/f0yI0z
Mar 24 12:52:23 <lsmith> kriswallsmith: thx!
Mar 24 12:52:23 <beberlei> jmikola|w yes
Mar 24 12:52:30 <lsmith> is there still something to be done where?
Mar 24 12:52:38 <lsmith> s/where/there
Mar 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
Mar 24 12:52:48 <Seldaek> kriswallsmith: great
Mar 24 12:52:59 <fabpot> lsmith: yes, I have not had time to have a look at it
Mar 24 12:53:03 * chirimoya has quit (Quit: Linkinus - http://linkinus.com)
Mar 24 12:53:17 <beberlei> Stof: you can change them, there is a parameter ofr it
Mar 24 12:53:29 <beberlei> was it removed?
Mar 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?
Mar 24 12:53:35 <Stof> beberlei: I just said it
Mar 24 12:53:36 <kriswallsmith> beberlei: can you update D bundles with the alias change?
Mar 24 12:53:40 * tystr (~firstname.lastname@example.org) has joined #symfony-dev
Mar 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?
Mar 24 12:53:52 <fabpot> lsmith: I just have a feeling, no hard facts
Mar 24 12:53:53 <beberlei> just remove the *BUndle or what?
Mar 24 12:53:53 <Stof> kriswallsmith: I will do that
Mar 24 12:54:05 <kriswallsmith> Stof: thanks
Mar 24 12:54:15 <kriswallsmith> beberlei: exactly
Mar 24 12:54:35 <avalanche123> I wanted to discuss mongodb session storage and where you think it makes sense to put it
Mar 24 12:54:59 <avalanche123> I have it implemented and working and we don't want to put it into http foundation
Mar 24 12:55:05 <avalanche123> but it doesn't rely on doctrine
Mar 24 12:55:07 <beberlei> bridge
Mar 24 12:55:13 <avalanche123> and uses raw Mongo class
Mar 24 12:55:26 <avalanche123> beberlei, how does it work?
Mar 24 12:55:29 <jstout> I'm with Saldaek on the forms.
Mar 24 12:55:48 <johanness> avalanche123, why don't you want to put it into http foundation?
Mar 24 12:55:53 <fabpot> beberlei: no, it's not a bridge as their is no third-party lib
Mar 24 12:56:02 <fabpot> johanness: because I don't want to
Mar 24 12:56:02 <lsmith> beberlei: so the PR didnt happen today .. will it happen tomorrow?
Mar 24 12:56:04 <beberlei> pecl/mongodb is sort of third party :D
Mar 24 12:56:06 <johanness> :)
Mar 24 12:56:07 <jmikola|w> avalanche123: is there a memcache driver in core?
Mar 24 12:56:18 <avalanche123> jmikola|w, not necessary
Mar 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
Mar 24 12:56:30 <lsmith> ok
Mar 24 12:56:30 <avalanche123> you just configure memcache with session support when compiling php
Mar 24 12:56:36 <avalanche123> jmikola|w ^
Mar 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.
Mar 24 12:56:40 <lsmith> so i think we need at least 24 hours to review the PR
Mar 24 12:56:47 <lsmith> before it makes sense to take a decision
Mar 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
Mar 24 12:56:52 * guilhermeblanco (~quassel@nat/yahoo/x-hoarhdgilokaksdg) has joined #symfony-dev
Mar 24 12:57:05 <lsmith> should we do an IRC meeting to discuss the last questions and vote on the weekend?
Mar 24 12:57:07 <avalanche123> Seldaek right
Mar 24 12:57:09 <beberlei> there will also be an Acme Bundle on the Forms
Mar 24 12:57:18 <lsmith> beberlei: great
Mar 24 12:57:23 <beberlei> so that everyone can see some use.cases, i am working on that tonight
Mar 24 12:57:28 <fabpot> lsmith: I will definitely need more than 24 hours
Mar 24 12:57:31 <avalanche123> so beberlei, HttpFoundationMongoBridge?
Mar 24 12:57:35 <jmikola|w> Seldaek: i was just considering if there was a problem conditionally supporting pecl extensions in core
Mar 24 12:57:42 <lsmith> ok .. so then a meetin on monday?
Mar 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?
Mar 24 12:57:46 <lsmith> or wait until next thursday
Mar 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
Mar 24 12:58:05 <lsmith> or only schedule a meeting if we feel we need one
Mar 24 12:58:20 <lsmith> otherwise just handle it via PR comments and mailinglist
Mar 24 12:58:22 <jmikola|w> Seldaek: Bulat legally can't cross any other borders, so we're good
Mar 24 12:58:27 <avalanche123> Seldaek, you can trust me ;)
Mar 24 12:58:31 <fabpot> lsmith: yes, let's discuss everything on the ML
Mar 24 12:58:35 <lsmith> ok
Mar 24 12:58:38 <avalanche123> jmikola|w haha
Mar 24 12:58:40 * henrikbjorn (~Henrik@188.8.131.52.generic-hostname.arrownet.dk) has joined #symfony-dev
Mar 24 12:58:41 <lsmith> so then meeting done