Development

IRCLogs20110317 (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of IRCLogs20110317

Show
Ignore:
Author:
lsmith (IP: 77.58.253.248)
Timestamp:
03/17/11 18:15:38 (7 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • IRCLogs20110317

    v0 v1  
     1= Summary = 
     2                          
     3http://www.doodle.com/iighzy7vfqc77943 
     4 
     5== RFC: Adding DI to Forms - experimental refactoring == 
     6 
     7== Configuration class improvements == 
     8 
     9== Whats missing for RC1? == 
     10 
     11== Adding MonologBundle in the core == 
     12 
     13== RFC: support for 405 Method Not Allowed responses == 
     14 
     15= IRC logs = 
     16{{{ 
     17[17:00] <lsmith> ok .. lets go 
     18[17:00] → [MA]Pascal joined the channel. 
     19[17:00] <lsmith> bschussek: ping 
     20[17:01] <[MA]Pascal> hi guys 
     21[17:01] → kertz joined the channel. 
     22[17:01] <bschussek> lsmith: pong 
     23[17:01] <lsmith> RFC: Adding DI to Forms - experimental refactoring: http://bit.ly/fuYIUd 
     24[17:02] <lsmith> your turn bschussek 
     25[17:02] <lsmith> where are we .. when will a pull be ready 
     26[17:02] <lsmith> how can we help 
     27[17:02] <lsmith> etc 
     28[17:02] <bschussek> ok 
     29[17:02] <bschussek> we currently have a new architecture 
     30[17:03] <bschussek> but things need to be cleaned up 
     31[17:03] <bschussek> that's what I'm working on right now 
     32[17:03] <lsmith> vicb: your topic is next btw 
     33[17:03] <bschussek> beberlei is working on a PhpTheme and helps me with feedback 
     34[17:03] <vicb> ok, getting prepared 
     35[17:03] <bschussek> I fear there's currently not much more anyone can do 
     36[17:03] <lsmith> ok .. is there a reason for waiting to merge this? 
     37[17:03] <lsmith> i mean its a gigantic change 
     38[17:04] <lsmith> and everybody is sitting on their hands waiting for it to appear 
     39[17:04] <bschussek> lsmith: yes. Some small features are currently broken 
     40[17:04] <lsmith> its the single biggest change before RC1 
     41[17:04] → everzet joined the channel. 
     42[17:04] <bschussek> I have to fix these before merging 
     43[17:04] <bschussek> and in order to fix these, things need to be cleaned up 
     44[17:04] <mvrhov> lsmith, you are forgeting about the Event change 
     45[17:05] <lsmith> basically we cannot release an RC1 earlier than 1 week .. likely 2 weeks after this has been merged 
     46[17:05] <bschussek> mvrhov is right. The event change was a big requirement for this merge 
     47[17:05] ← Nenuial left IRC. (Read error: Operation timed out) 
     48[17:05] <johnwards> bschussek: The event code is in the branch is that complete and will that be in the same pull request? 
     49[17:05] <bschussek> as it looks, the event code is merged today 
     50[17:05] <lsmith> mvrhov: the event hcnage isnt "big" 
     51[17:05] <bschussek> lsmith: no, but Form relies on it 
     52[17:06] <lsmith> fabpot: ping 
     53[17:07] → Nenuial joined the channel. 
     54[17:07] <fabpot> I think I won't be able to merge the new event system today 
     55[17:07] <fabpot> I'm still reviewing the patch, and discussing some renaming with bschussek 
     56[17:08] <fabpot> I'm also converting the FrameworkExtraBundle to the new system to have a better feeling for it 
     57[17:08] <fabpot> so, hopefully, this will land into master tomorrow 
     58[17:08] <fabpot> lsmith: and yes, the new form is the last thing we are waiting for 
     59[17:08] <fabpot> by the way, it's not clear that it will land or not right now 
     60[17:09] <fabpot> I have raised some concerns to bschussek, and they need to be fixed before we can consider merging it 
     61[17:09] <johnwards> bschussek: I'm using your branch. Do you need help? Or are you happy for me to write tests? 
     62[17:09] ← julbou left IRC. (Ping timeout: 250 seconds) 
     63[17:09] <bschussek> johnwards: you can write tests 
     64[17:09] → DeluxZ joined the channel. 
     65[17:09] <bschussek> there are some tests missing for the value transformers, for example 
     66[17:09] <lsmith> maybe it would be better to create a WIP PR 
     67[17:09] <lsmith> so that we have a centralized place for feedback? 
     68[17:10] <bschussek> lsmith: talking about forms or events? 
     69[17:10] <Stof> events still have a PR so I guess forms 
     70[17:10] <lsmith> forms 
     71[17:10] ← [MA]Pascal left IRC. (Quit: [MA]Pascal) 
     72[17:11] <lsmith> ok .. is there anything else for this topic? 
     73[17:11] <johnwards> timeline? 
     74[17:11] <bschussek> lsmith: I'm not sure it already makes sense at this point. Most people will complain about things that are going to be changed anyway 
     75[17:12] → [MA]Pascal joined the channel. 
     76[17:12] <lsmith> seems like the opensky guys are sleeping again .. Seldaek too? 
     77[17:12] <bschussek> i.e., small convenience things, order of arguments, such stuff 
     78[17:12] <Seldaek> lsmith: nah 
     79[17:12] <Seldaek> lsmith: just don't want to enter the forms debate:p 
     80[17:12] <lsmith> bschussek: do you have an ETA? 
     81[17:12] → ahilles107 joined the channel. 
     82[17:13] <bschussek> hopefully end of next week 
     83[17:13] <lsmith> ok :-/ 
     84[17:13] <fabpot> bschussek: I think we cannot wait much more than that 
     85[17:13] <Seldaek> bschussek: are you *sure* you can't delegate some stuff? 
     86[17:13] <bschussek> Seldaek: I can delegate testing, I can't delegate the cleanup because then I'd spent more time explaining than actually working 
     87[17:14] <bschussek> fabpot: ok 
     88[17:14] <Seldaek> I somehow doubt that but ok.. 
     89[17:14] <johnwards> I can also chip in with little fixes as I'm actually using the code to develop 
     90[17:14] <rande> why we cannot wait more ? 
     91[17:14] <lsmith> meaning we kind of need a "final" version by mid next week to review 
     92[17:14] <lsmith> so that we can vote on if we want the change in during the next meeting 
     93[17:14] <fabpot> rande: because people expect us to release something, people expect us to have documentation, ... 
     94[17:15] <lsmith> work out last details and then merge over the weekend 
     95[17:15] <fabpot> if we don't move fast, we will loose the momentum 
     96[17:15] <weaverryan> I agree - time to close things off 
     97[17:15] <lsmith> can someone else take over the event stuff in case there is still stuff to do? 
     98[17:15] <beberlei> now here, customer 
     99[17:15] <fabpot> lsmith: I think it won't need much work, so I will 
     100[17:15] <lsmith> is there some austrian that can take over bschussek's laundry and house work chores? :) 
     101[17:16] <johnwards> Is the form refactoring not a decided on thing? Especially after the talk at sflive2011 it seemed like thats its a definite in? 
     102[17:17] <beberlei> generally people are concerned by the DICish look, but its perfectly self-sustainable, and even easy so, we just have to get the convenience for it done, first integration into framework is important 
     103[17:17] <fabpot> johnwards: no, it's not. As I said, I raised some concerns and they need to be fixed. But bschussek agreed on them and they should be fixable 
     104[17:17] <lsmith> ok 
     105[17:17] <lsmith> so lets move on 
     106[17:17] <lsmith> vicb: Configuration class improvements: http://bit.ly/gZ2giC, http://bit.ly/fe4DC8 
     107[17:17] <lsmith> johanness, Stof are you guys around too? 
     108[17:17] <Stof> I'm here 
     109[17:18] <vicb> The main idea was to be able to easily generate docs & xsd 
     110[17:18] <kertz> Is there a todo list ordered on priority with who's working on what? 
     111[17:18] <vicb> It also comes with some other benefits detailed in the PR 
     112[17:18] <vicb> Johannes has agreed on integrating the changes 
     113[17:19] <lsmith> the PR is the second link .. aka https://github.com/symfony/symfony/pull/303 
     114[17:19] <vicb> So I think they should be integrated asap 
     115[17:19] <vicb> There is one thing left to be done: 
     116[17:19] <fabpot> I can merge it when it's ready and if we all agree 
     117[17:19] <fabpot> I'm +1 
     118[17:19] <vicb> test the config for the security component 
     119[17:20] <jmikola|w> i didn't understand what adding a children() block accomplished, but the migration looks very painless and i trust your judgement 
     120[17:20] <vicb> i don't have a proper setup to exercize all the options 
     121[17:20] <Stof> I'm +1 too 
     122[17:20] <jmikola|w> weaverryan: did you give this a look? i think you were playing with some config console task? 
     123[17:20] <vicb> Any volunteer to help with security ? 
     124[17:20] → seb_m joined the channel. 
     125[17:20] <Stof> vicb: you will need to rebase it because there is some changes in the configuration classes since you did it 
     126[17:20] → julbou joined the channel. 
     127[17:20] <vicb> I have a rebased version I can push 
     128[17:20] <Stof> at least SwiftmailerBundle 
     129[17:21] <jmikola|w> was FrameworkBundle already migrated? 
     130[17:21] <fabpot> vicb: you can probably test with the new Symfony SE, as we have a simple security config 
     131[17:21] <weaverryan> jmikola|w: I haven't in detail, but I don't think it'll affect anything (and if so, it'll be positive) 
     132[17:21] → henrikbjorn joined the channel. 
     133[17:21] <vicb> All the core extension have been migrated 
     134[17:21] <Seldaek> jmikola|w: aye, didn't really get the children() calls, but it's no big deal 
     135[17:22] <Stof> jmikola|w: all bundle are migrated in the PR 
     136[17:22] <vicb> i can try SE but if anyone has a setup with security enabled that should really be a matter of pulling the branch and testing 
     137[17:22] <Stof> vicb: the latest SE ahs the security enabled 
     138[17:23] <jmikola|w> kriswallsmith: i think we can test this out with opensky once it's in core :) 
     139[17:23] <jmikola|w> we have a rather gigantic security configuration 
     140[17:23] <vicb> I'll push my branch right after the meeting then 
     141[17:24] <lsmith> ok sounds good 
     142[17:24] <lsmith> next topic then i guess 
     143[17:24] <vicb> Then there will be some work to do to generate the docs but is this the topic ? 
     144[17:24] <vicb> ok 
     145[17:25] <jmikola|w> vicb: that's a separate task, and likely something we can work on after RC1 is released :) 
     146[17:25] <lsmith> right 
     147[17:25] <jmikola|w> no BC concerns 
     148[17:25] <lsmith> so next topic is Whats missing for RC1? 
     149[17:25] <vicb> agree 
     150[17:25] <lsmith> obviously the form stuff 
     151[17:26] <lsmith> anything else critical that is missing? 
     152[17:26] <johanness> not so sure... 
     153[17:26] <johanness> if we don't plan for having doc generation, it might not work 
     154[17:26] <fabpot> as far as the code is concerned, I think it's mainly the form stuff 
     155[17:26] <fabpot> but we also need to think about the service names before going RC1 
     156[17:27] <fabpot> besides some inconsistencies, getting the Doctrine manager for instance is quite verbose 
     157[17:27] <vicb> I think defining an interface for the Configuration clss might be enough ? 
     158[17:27] <jmikola|w> johanness: i think we needed a way to add doc comments (since closures can't be turned into descriptive text easily), but other than that, i don't see problems inferring documentation based on the config structure (can discuss later if you like) 
     159[17:27] <fabpot> so, we need to list all service names and see if we can come up with better names 
     160[17:27] <everzet> fabpot: +1. Some service names is really to verbsoe 
     161[17:27] → old_sound joined the channel. 
     162[17:28] <everzet> *are really too verbsoe 
     163[17:28] <everzet> *verbose 
     164[17:28] <jmikola|w> fabpot: should we have a best practice for naming services? i think a leading vendor name certainly helps, so perhaps the default EM could be doctrine.entity_manager 
     165[17:28] <lsmith> fabpot: what about bridges? 
     166[17:28] <lsmith> and the other stuff we discussed in paris 
     167[17:28] <lsmith> http://trac.symfony-project.org/wiki/SfliveParisDevMeeting 
     168[17:29] <lsmith> "default scope" 
     169[17:29] <fabpot> lsmith: I know we have some other things, I just wanted to talk about things we don't have yet on our radar 
     170[17:29] <lsmith> k 
     171[17:30] <[MA]Pascal> i think we need more tests (core + bundles + SE) 
     172[17:30] <johnwards> Do we have a list of all the things on the radar? Is that the dev meeting notes? 
     173[17:30] <jmikola|w> johnwards: i think the paris meeting notes lsmith posted above + what we're discussing here should be it 
     174[17:30] <beberlei> i agree pascal, i found some stuff that is entirely untested 
     175[17:31] <beberlei> mostly stuff thta is only good to test on a functional level, but still missing 
     176[17:31] <johanness> btw, do we have functional tests atm? 
     177[17:31] <beberlei> what i fear is that with all the unittests we dont see when larger stuff with the DIC config changes 
     178[17:31] <beberlei> unittests wont see this at all 
     179[17:32] <johanness> especially for the security listeners functional tests would make sense imo 
     180[17:32] <jmikola|w> when i was dabbling with frameworkbundle, i wrote its extension test functionally (reads config files)... but i know not all the extensions do that - some are strictly unit 
     181[17:32] <beberlei> maybe we even need some example applications 
     182[17:32] <beberlei> yah security extension is probably the best example where a full app test would probably be nececssary 
     183[17:33] <jmikola|w> beberlei: perhaps that could be achieved by making some webtests in the sandbox application, that load some controllers - security could be added there, too 
     184[17:33] <jmikola|w> i'm not sure where such tests would fit in within the main symfony repository 
     185[17:33] <beberlei> you dont run the sandbox tests in conjunction with the symfony tests 
     186[17:33] <beberlei> tests/apps/demo1/* 
     187[17:33] <beberlei> you obviously dont need the vendor in there, you already have that 
     188[17:34] ← old_sound left IRC. (Quit: old_sound) 
     189[17:34] ← carlossg_00 left IRC. (Quit: Leaving) 
     190[17:34] <[MA]Pascal> +1 for a hardened distribution 
     191[17:35] <everzet> separate test distribution? 
     192[17:35] <everzet> +1 then 
     193[17:35] <beberlei> nah, nobody uses that 
     194[17:35] <fabpot> as the directory structure for an app is quite flexible, it can be just a bunch of configuration files and some controllers/templates 
     195[17:35] <pgodel_work> everzet: I was thinking exactly the same 
     196[17:35] <fabpot> all tests should be in the main repository 
     197[17:36] <everzet> then we can do something, like i dit in BehatBundle 
     198[17:36] <beberlei> whats the problem with putting together very small apps in the test folder? i cant see a downside 
     199[17:36] <everzet> create test controllers/views under the Test namespace in bundle itself 
     200[17:36] <johnwards> +1 on the BehatBundle tests. Works well 
     201[17:37] <jmikola|w> beberlei: putting test apps in a test folder sounds fine, esp if the directory structure is flexible (we can take shortcuts :) 
     202[17:38] <fabpot> beberlei: +1 
     203[17:38] <fabpot> jmikola|w: yes, we will take shortcuts 
     204[17:38] <Stof> +1 
     205[17:38] <jmikola|w> fabpot: are we going to move tests into the actual components? 
     206[17:38] <fabpot> jmikola|w: no 
     207[17:39] <everzet> jmikola|w: no 
     208[17:39] ← julbou left IRC. (Quit: julbou) 
     209[17:39] <everzet> jmikola|w: you don't need functional web tests inside components. Only in the bundles 
     210[17:39] <jmikola|w> everzet: i was talking about unit tests 
     211[17:39] → dbenjamin joined the channel. 
     212[17:39] <everzet> jmikola|w: ah, you're talking bout unit-tests. sorry :-/ 
     213[17:40] <lsmith> ok .. anything else that is missing for RC1 that might not be on our radar yet? 
     214[17:40] <jmikola|w> yeah, looking at https://github.com/symfony/Templating i realize there are no tests there 
     215[17:40] <lsmith> ok moving on then 
     216[17:40] <lsmith> Seldaek: Adding MonologBundle in the core: http://bit.ly/eryhFl 
     217[17:41] <Seldaek> well, there isn't much to say I guess everyone knows what it's about 
     218[17:41] <Seldaek> all we need is a decision 
     219[17:42] <[MA]Pascal> everzet: yeah i was talking about functional tests too .. 
     220[17:42] <Seldaek> there are a few advantages (FingersCrossedHandler, flexibility of development - ever tried contributing to ZF?, multiple logging channels - which could allow filtering of this or that log channel easily in the profiler) 
     221[17:43] <Seldaek> afaik there is no drawback and if there's one I'm pretty sure we can work on fixing it 
     222[17:43] <jmikola|w> Seldaek: would this work like assetic? bundle in core and the main library in your repo? 
     223[17:44] <pgodel_work> log rotation is pretty nice too 
     224[17:44] <Seldaek> jmikola|w: yes, it's also API compatible, so there really is not much of a change required in core to support either logging library 
     225[17:44] <jmikola|w> i stuff you presented during unconf at sflive looked good, so i have no objections 
     226[17:44] <Seldaek> pgodel_work: aye, that's not there yet though, but definitely planned 
     227[17:44] <jmikola|w> things like fingerscrossed defintely could make debugging sf apps easier (when you tail logs) 
     228[17:44] <beberlei> can someone explain this finger crossing? 
     229[17:44] <jmikola|w> for anyone unaware, it basically doesn't log anything unless a serious error pops up 
     230[17:45] <jmikola|w> then you get the full log (all levels) 
     231[17:45] <Stof> jmikola|w: the current implementation also uses a separate vendor for logs 
     232[17:45] <lsmith> it should be noted that switching from monolog to zend\log is trivial 
     233[17:45] <lsmith> however the reason to have monolog in core is that the internal services would then be tagged properly out of the box 
     234[17:46] <beberlei> tagged as what? 
     235[17:46] <johnwards> I have yet to see a negative opinion on including this. Anyone wish to play devils advocate? 
     236[17:46] <beberlei> ah you mean vs not tagged if monolog is not in core 
     237[17:46] <snc_hw> beberlei: logging channels 
     238[17:46] <Seldaek> beberlei: the tags define the logging channel that every service using the logger will use 
     239[17:47] <[MA]Pascal> Seldaek: i rly like it, my only concern so far is the CRAP/Cyclomatic Complexity score of some methods (foreach->foreach->if->foreach->if in LoggerChannelPass e.g.) 
     240[17:47] <Seldaek> beberlei: that way, all db stuff is tagged as "db" channel and can be filtered out easily (that's just an example..) 
     241[17:47] <johanness> Seldaek, one logger can log only one channel? 
     242[17:47] → dustinwhittle joined the channel. 
     243[17:47] <fabpot> johnwards: I can 
     244[17:47] <Stof> [MA]Pascal: this is needed because of the way the tag work. you need to loop over the tags of the tagged services 
     245[17:47] <johnwards> I thought that might be the case fabpot ;) 
     246[17:48] <fabpot> that's yet another thing that comes late in the game 
     247[17:48] <Stof> but it is only done at compile time 
     248[17:48] <Seldaek> johanness: yes, the logger instance *is* the channel, but you could extend it and support multiple channels if you really have a use case 
     249[17:48] <fabpot> and nothings comes for free 
     250[17:48] <fabpot> so, I will only consider adding it to the core when full documentation and tests are available 
     251[17:48] <pgodel_work> fair enough 
     252[17:49] ← ornicar left IRC. (Ping timeout: 252 seconds) 
     253[17:49] <Seldaek> fabpot: might as well have told me that two weeks ago when I asked though.. I'm not avail this weekend :/ 
     254[17:49] <Stof> I could advocate the opposite by saying Assetic is in the core without doc :) 
     255[17:49] <Seldaek> yeah, also there are really not that many docs required, it's so trivial to use 
     256[17:49] <lsmith> i agree with requiring tests 
     257[17:49] <Stof> (and ZendBundle is not documented either) 
     258[17:50] <Seldaek> and from the end user perspective, it acts just like Zend\Log 
     259[17:50] <[MA]Pascal> + 1 for no need to doc but +1 for full coverage unittest 
     260[17:50] <Seldaek> you can't really distinguish them 
     261[17:50] <lsmith> but doc's is something that should be committed to be provided before a stable release 
     262[17:50] <Seldaek> monolog itself is tested 
     263[17:50] <fabpot> Seldaek: I'm just a bit upset right now because I've already spent 2 hours debugging the new event system and fixing bugs 
     264[17:51] <Seldaek> fabpot: well, I can understand, but this isn't the same kind of core change, the Logger interface is clearly defined and respected.. 
     265[17:51] ← dbu left IRC. (Remote host closed the connection) 
     266[17:51] <Seldaek> fabpot: the PR is probably out of date compared to core though, but I can fix that easily if we agree to merge it 
     267[17:51] <fabpot> Seldaek: I know the story. Don't be worry, this is a very simple change, ... 
     268[17:51] <Stof> the compiler pass is tested so the only missing test is the DI extension. I can write them this evening 
     269[17:51] <[MA]Pascal> Seldaek: so testing the bundle should be trivial 
     270[17:51] ← dustinwhittle left IRC. (Client Quit) 
     271[17:52] <fabpot> again, someone ask for a devil advocate, that's what I'm trying to do now ;) 
     272[17:52] <Seldaek> [MA]Pascal: yes, see Stof's comment 
     273[17:52] <lsmith> ok .. so then lets vote? 
     274[17:52] <Seldaek> fabpot: yeah well, there is devil's advocate and abusive devil :p 
     275[17:52] <Stof> and I can rebase it before that 
     276[17:52] <Stof> +1 
     277[17:53] <Seldaek> +1 (in case it wasn't clear..) 
     278[17:53] <fabpot> whatever the vote result will be, it must be mergeable by the end of next week 
     279[17:53] <rande> +1 
     280[17:53] <johnwards> +1 
     281[17:53] <vicb> +1 
     282[17:53] <kertz> +1 
     283[17:53] <Seldaek> fabpot: no problem 
     284[17:53] <snc_hw> +1 
     285[17:53] <igorw> +1 
     286[17:53] <[MA]Pascal> +1 
     287[17:53] <Stof> I can do it mergeable this evening 
     288[17:53] <kriswallsmith> -0 
     289[17:53] <rande> ;) 
     290[17:54] <[MA]Pascal> kriswallsmith: bad boy 
     291[17:54] <lsmith> ok next topic 
     292[17:54] <Seldaek> kriswallsmith: disagreeing for the sake of it? :p 
     293[17:54] <fabpot> and of course, someone (Seldaek?) should be committed to maintain monolog for the forseable 
     294 future 
     295[17:54] <naderman> -? 
     296[17:54] <lsmith> RFC: support for 405 Method Not Allowed responses: http://bit.ly/fCwcJC 
     297[17:54] <lsmith> kriswallsmith: 
     298[17:54] <lsmith> go fast .. :) 
     299[17:54] <kriswallsmith> i think we should support 405 responses 
     300[17:54] <Seldaek> fabpot: sure, I don't plan on dropping Sf2 any time soon :) 
     301[17:54] <kriswallsmith> if the pathinfo points to a known resource but the method is not supported 
     302[17:55] <kriswallsmith> that's what this patch is 
     303[17:55] <[MA]Pascal> Seldaek: i will add Monolog to our jenkins ci platform today 
     304[17:55] <kriswallsmith> it changes a few parts of the router interface 
     305[17:55] <henrikbjorn> i would like to raise something with this, we need to find a uniformed way of handling response codes, exceptions or returning response objects (NotFound 404 and other non successful responses) 
     306[17:55] <kriswallsmith> the match method throws an exception instead of return false 
     307[17:55] <lsmith> henrikbjorn: http://webmachine.basho.com/diagram.html 
     308[17:55] <fabpot> I'm +1 for this PR, I think it's far cleaner than the current code 
     309[17:55] <kriswallsmith> henrikbjorn: i've tried to do that here 
     310[17:56] → dustinwhittle joined the channel. 
     311[17:56] <kriswallsmith> the router throwing an exception rather than returning false is the main change 
     312[17:56] <fabpot> but the patch is not mergeable yet as the Apache Dumper is not updated yet 
     313[17:56] <kriswallsmith> right 
     314[17:56] <henrikbjorn> also the redirect is a response that should be an exception then 
     315[17:57] <kriswallsmith> that's outside the scope of this pr 
     316[17:57] ← seb_m left the channel. 
     317[17:57] <kriswallsmith> so, any objections? 
     318[17:57] <kriswallsmith> not sure what there is to discuss... 
     319[17:57] <kriswallsmith> it's just a cool thing to say we support :) 
     320[17:57] <henrikbjorn> yes i know but still a a concern that the handling of theese are inconsistent. 
     321[17:57] <johanness> i also like to have a general concept for exception vs response 
     322[17:57] <henrikbjorn> +1 from me 
     323[17:58] <henrikbjorn> Maybe the rule should be exceptions for everything not 2xx ? 
     324[17:58] <kriswallsmith> let's discuss exception v. response next week 
     325[17:59] <kriswallsmith> i'll assuming we're overwhelmingly in favor of my PR :) 
     326[17:59] <henrikbjorn> sure 
     327[17:59] <Seldaek> henrikbjorn: I don't think 3xx wararnt an exception 
     328[17:59] <kriswallsmith> OT 
     329[17:59] <Seldaek> having exceptions for the errors makes sense 
     330[17:59] <kertz> Seldaek: +1 
     331[17:59] <kriswallsmith> alright, meeting adjourned? 
     332[18:00] <Seldaek> kriswallsmith: other than that, on principle I agreee this has to be supported 
     333[18:00] <henrikbjorn> Seldaek: that might be right, but it would skip the response process because it will be catched early 
     334[18:00] <fabpot> so, let's open a discussion on exception vs response on the dev mailing-list (no need to wait for next week) 
     335[18:00] <lsmith> yes .. so yeah .. meeting over 
     336}}}