<ac:macro ac:name="toc" />
<li>Date: 04 April 2012, 18:00-19:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-04-04 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 11 April 2012</li>
<h3>OAuth 2.0 integration and where it should live</h3>
<p>(Search for "18:01:44" in the log.)</p>
<p>Gary Hockin (Spabby) is working on OAuth2 support for the framework. This support will include both client and server implementations. For the client side, things get dicey as (a) server-side implementations differ and vary from the specification, and (b) require round trips by the end-user to and from the provider. As such, Gary is unsure whether to develop OAuth2 as a service component, a module, or a ZF2 component.</p>
<p>Debate showed that the core functionality surrounding the computational aspects could likely live within the framework, but that for consumers and even providers, it may make sense to have drop-in modules that simply accept some configuration to make work.</p>
<p>Overall, the only consensus reached was that an RFC is needed to better illustrate the issues so that we can have a truly informed vote. Dolf Schimmel (Freeaqingme) volunteered to begin the RFC, and have Gary and Mike Willbanks (mwillbanks, who plans to work on the provider aspect of the component) review.</p>
<p><strong>tl;dr</strong>: Expect an OAuth2 RFC shortly.</p>
<p>(Search for "18:22:36" in the log.)</p>
<p>Enrico Zimuel (ezimuel), in getting feedback on his Zend\Crypt proposal, was given the suggestion to move the Zend\Crypt\BigInteger component under Zend\Math. This re-opened the discussions around Zend\Math. Enrico suggests going forward with the Zend\Crypt proposal, but moving math-related code under the Zend\Math namespace, but without waiting for approval on the Zend\Math component. This had unanimous support.</p>
<p>Marco Pivetta (ocramius) raised some more questions about Zend\Crypt's API, suggesting to make it even simpler; specifically, he wanted the possiblity of specifying all parameters, including the key, via class options rather than passing them to the enc()/dec() methods. Enrico agreed to consdier this change.</p>
<p><strong>tl;dr</strong>: We'll have a Zend\Math component as part of Zend\Crypt refactoring.</p>
<h3>Changing meeting times</h3>
<p>Finally, Matthew (weierophinney) suggested changing the time for IRC meetings. Originally, meetings were set for 17:00 UTC, but when DST ended last fall moved forward to 18:00 UTC. Now that DST is back, he suggested changing the time again. While a good number voted for 17:00, some late comers indicated that the new time did not necessarily work, and several others at that time also indicated the same. Matthew suggested asking on the ML and creating a poll based on suggested times.</p>
<p><strong>tl;dr</strong>: DST messes with everybody's schedules.</p>
<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
white-space: -moz-pre-wrap; /* Mozilla, supported since 1999 */
white-space: -pre-wrap; /* Opera 4 - 6 */
white-space: -o-pre-wrap; /* Opera 7 */
white-space: pre-wrap; /* CSS3 - Text module (Candidate Recommendation) http://www.w3.org/TR/css3-text/#white-space */
word-wrap: break-word; /* IE 5.5+ */
border: 1px solid darkgray;
17:59:34 <weierophinney > Greets, all!
17:59:37 < Spabby > hi!
17:59:38 <weierophinney > time to start!
17:59:45 < ezimuel > hi all!
17:59:46 < ocramius > hiall
17:59:47 < Bittarman > Evening chaps
17:59:55 <weierophinney > Reminder: agenda is here: http://bit.ly/H96AcG
18:00:14 < Thinkscape > wiki is back!
18:00:17 <weierophinney > Meeting is logged so that we can post a log and summary later, so don't say anything you don't want public.
18:00:23 < ocramius > ezimuel: /me goes to read Math rfc... forgive me ezimuel :\
18:00:26 <weierophinney > Thinkscape: yep, I kicked it good a few minutes ago.
18:00:44 < ezimuel > ocramius: ok
18:00:46 <weierophinney > ocramius: math rfc was written by WalterTamboer originally, and has been posted for months.
18:01:16 < Thinkscape > Calendar & updates : I don't understand what's written in the wiki...
18:01:23 < Thinkscape > Is it spanglish ?
18:01:26 <weierophinney > Looking at the agenda.. first topic we're skipping, due to more votes against discussing than for, plus technical reasons not to consider it.
18:01:27 < ocramius > weierophinney: then I probably missed the correct rfc
18:01:30 <weierophinney > Thinkscape: see above.
18:01:40 < Thinkscape > ugh
18:01:44 <weierophinney > Next topic, though, is good: OAuth 2 integration.
18:01:49 <weierophinney > Spabby: you around to take this one?
18:01:58 < Spabby > yep
18:02:08 < EvanDotPro > weierophinney: actually i had just tied the vote, but A) it was after the meeting started by a minute and B) i'm okay with skipping that topic.
18:02:17 <weierophinney > EvanDotPro: noted.
18:02:40 <weierophinney > EvanDotPro: ezimuel wanted to change his vote anyways.
18:02:44 <weierophinney > Spabby: GO FOR IT
18:02:53 < Spabby > basically, we have been trying to get some momentum going for OAuth 2.0 integration into the framework, starting with a client but extending to a server as well
18:03:27 < Spabby > we've bashed out some of the architecture issues this week, but the question is where should this component live, in the framework proper, as a service module, or somewhere else?
18:04:16 <weierophinney > My take is that this is a nice utility class, in that it might be consumed by a variety of services, and, with the server, allow providing an oauth2 provider. As such, I'd vote for inside the framework.
18:04:25 <weierophinney > But, as you note, where?
18:04:26 < ocramius > I'm fine with having it as module, it really is just a Module additional class in the namespace
18:04:49 <weierophinney > ocramius: do you prefer having it as a module, or are you simply "fine" with having it as a module?
18:04:57 < ocramius > I prefer it as a module
18:04:57 <weierophinney > and what's the argument for making it a module vs. a component?
18:04:59 < Spabby > there has been some support to have it in the framework proper, but also some support to have it as a ZendService module, my favourite so face has been to have Zend\Oauth\OAuth1 \OAuth1A and \OAuth2 but we are then tied into having it only updating on framework releases
18:05:12 < ocramius > a module could provide some initialization logic (bootstrap) that helps devs getting started
18:05:14 * Thinkscape_ is back...
18:05:23 < Thinkscape_ > umm... wouldn't it be better to create an Auth component with adapters? i.e. for openid, browserid, oauth, windows live id etc.
18:05:28 < ocramius > OAuth is not always easy, and some guidance by the module maintainer isn't bad
18:06:01 < ocramius > Also, (I don't know if this fits the topic) the OAuth 2 current impl should probably be splitted into client and server probably...
18:06:02 < Thinkscape_ > there are also a few "modern" coming soon ...
18:06:03 <weierophinney > ocramius: you're talking about it in terms of integration, due to the need to do redirects, etc.?
18:06:12 < ocramius > weierophinney: yes, indeed
18:06:24 < Spabby > if I can provide some background, the idea is to have a default Options class, with bespoke Options classes for the popular vendors so you can connect it into the popular sites very quickly
18:06:27 < ocramius > weierophinney: providing some simple options like "initialize for google"
18:06:28 < ezimuel > We can have other service components that use OAuth so I vote to put it in a component
18:06:42 < ocramius > Spabby: saw your example for google
18:06:49 <weierophinney > Thinkscape_: we have an adapter-based authentication component already... but I thinmk the point being made is that oauth differs from the other adapters due to the request/response lifecycle necessary.
18:06:54 < ocramius > it is nice, but it could be provided with a module config
18:07:09 < Thinkscape_ > weierophinney: I disagree. There are other protocols similar to it.
18:07:11 < EvanDotPro > Thinkscape_: honestly thats kinda what ZfcUser does: providing a more powerful auth component (extending Zend\Authentication) so that adapters can be made for oauth, browserid, etc.
18:07:22 < Bittarman > I think it makes more sense as a module...
18:07:26 < Thinkscape_ > weierophinney: and the new ones that will come in the next few months will sometimes even use tokens (i.e. mobile apps)
18:07:40 < ocramius > Spabby: also, I am not sure if this fits the topics, but for now the client and the OAuth lib are one thing, right spabby?
18:07:42 < Bittarman > then it makes sense to consumers of it why it has some features which integrate with the MVC
18:08:03 <weierophinney > Thinkscape_: yes, but the tokens can be injected into the adapters, which then simply provide validity of identity and identity.
18:08:09 < Bittarman > because if it doesn't do that, its going to mean alot of people writing essentially the same boilerplate in order to use it.
18:08:14 < Thinkscape_ > ezimuel: other components should use Authentication component — the choice of adapter, oauth or otherwise - should be left to the user.
18:08:20 < EvanDotPro > Thinkscape_: there's ones that require an app where you scan the QR code on your mobile device and stuff... lots of clever two-factor auth services, which Zend\Authentication does NOT cleanly support.
18:08:24 < mwillbanks > I believe that the base "Component" so to speak should be in the core, with vendor specifics being in modules
18:08:36 < Spabby > if it is a component, it should return something that lets the calling class know they need to perform a redirect, rather than do the redirect, if it's a module then it can be configured to do that redirect
18:08:40 < Thinkscape_ > EvanDotPro: my point: OAUTH living in vacuum won't be a good component.
18:09:02 < Thinkscape_ > Regardless of how protocol works..
18:09:38 < Bittarman > s/component/module/
18:09:44 <weierophinney > Thinkscape_: right... I think good points have been made at this point to have it as a module for that reason. But it raises the question of whether or not we need to make changes to the Authentication component.
18:10:10 < Bittarman > have it as a component, then by the rules we are working to for other components, it will be unaware of the MVC.
18:10:19 < ocramius > weierophinney: the adapter could be provided by the module, this reduces dependencies in the framework
18:10:23 < Bittarman > and therefore more complex for developers to use.
18:10:27 < Thinkscape_ > Bittarman: we can always make it aware with strategies.
18:10:30 < Bittarman > as a module, its more drop in, and go.
18:10:32 < DASPRiD > meeting!
18:11:04 < Thinkscape_ > Ok, that leaves the questions: what is the use case for the component without a module then ?
18:11:05 < Spabby > I may be missing the point, but OAuth doesn't actually provide authentication information for the user, it only provides the token to acquire that information
18:11:19 < ocramius > Spabby: yes, but an auth adapter could consume oauth services
18:11:31 < Spabby > ocramius: yes indeed
18:11:37 < ocramius > Spabby: so it would be "helpers" provided by the oauth module
18:11:43 <weierophinney > Spabby: the Authentication component does two things: verify identity, and provide identity.
18:12:01 < Thinkscape_ > Spabby: are oauth services used outside of auth component ?
18:12:18 < Spabby > Thinkscape_: sorry, I don't understand what you mean
18:12:27 < mwillbanks > Thinkscape_: absolutely; especially when you get into the server component
18:12:31 < Thinkscape_ > if not - then it could be Auth\Adapter\Oauth
18:12:41 < Spabby > ^^^ ta mwillbanks
18:12:51 < Thinkscape_ > Instead of Zend\Oath - which is detached and quite useless... i propose Zend\Authentication\Adapter\Oauth + common framework for that
18:12:55 < DASPRiD > weierophinney> Looking at the agenda.. first topic we're skipping, due to more votes against discussing than for, plus technical reasons not to consider it. <<<< 7 yes, 5 no :x
18:13:12 < EvanDotPro > Thinkscape_: i'd say yes... for example, we could have modules.zf.com with a normal email/password account system, but then you can simply add/link your github account to your existing account.
18:13:18 < SpiffyJr > Thinkscape_, OAuth also has a provider component on top of the consumer (auth) portion.
18:13:22 <weierophinney > DASPRiD: I was looking at it prior to the meeting. Votes have changed since then.
18:13:32 <weierophinney > DASPRiD: that said, I know of at least one switch from yes to no.
18:13:33 < SpiffyJr > Thinkscape_, I'm not sure if Spabby is implmenting a provider portion but Zend\OAuth seems reasonable to me.
18:13:49 < Spabby > EvanDotPro: that would be the job of ZendService\GitHub, which would consume Zend\OAuth
18:14:01 < ocramius > Spabby: just to know, do you have plans to separate the client within the OAuth module?
18:14:02 < Spabby > I guess a key question is, are we going to support all 3 version of OAuth?
18:14:04 < mwillbanks > The PROVIDER in an OAUTH component also provides ACL what you can and what you cannot do... when talking SPECIFICALLY about the CONSUMER portion yes; that could CONTAIN an Authentication adapter
18:14:05 < EvanDotPro > Thinkscape_: in that case, they'r already authenticated as far as the site is concerned, but oauth is used in a different capacity to aquire a token for accessing the GitHub API via that user.
18:14:05 < mwillbanks >
18:14:10 < DASPRiD > weierophinney, i wonder what's the general consensus there is about moving all atlassian product to "hosted"
18:14:11 < ocramius > currently, OAuth itself is the client
18:14:18 < DASPRiD > weierophinney, but different story, ignore me
18:14:29 < ocramius > (and the OAuth server side libs out there really suck )
18:14:45 < Spabby > mwillbanks will be leading a server side lib I believe
18:15:03 < mwillbanks > Freeaqingme also volunteered to help
18:15:06 < ocramius > hmm, and shouldn't that be under the same ns?
18:15:21 < Spabby > if we are going to support OAuth 1, 1A and 2 then I propose Zend\Oauth\OAuth2\Client
18:15:35 < ocramius > that's why I'm asking if there's plans for separating the client (even just naming could do)
18:15:41 < mwillbanks > ocramius: it would be... there might need to be some additional separation but there will likely be some commonality to things.
18:15:46 < Spabby > or ZendService\Oauth\OAuth2\Client
18:15:53 < Freeaqingme > Spabby, for a provider, I could see some adapter based pattern
18:15:58 < Freeaqingme > uhm, s/provider/client
18:16:00 < Spabby > Freeaqingme: agreed
18:16:11 < Freeaqingme > that's a bad typo...
18:16:20 < EvanDotPro > my vote is that OAuth code pertaining to the implementation of the OAuth spec can live under Zend\OAuth, then vendor-specific integrations can be delivered as modules.
18:16:42 < Spabby > Freeaqingme: because we will be providing both client and server I think it should live in it's own sub-namespace
18:16:51 < Freeaqingme > EvanDotPro, that's a discussion that will need to be held later. Another option would be to put it in components under zendservice
18:17:04 < mwillbanks > EvanDotPro: that is what i was thinking... inside of there as well could be an authentication adapter as well that could then allow for more loose coupling
18:17:08 < Spabby > EvanDotPro: I disagree, it would mean creating a load of ZendService modules that contained only option classes for the OAuth client
18:17:10 < Freeaqingme > Spabby, but 1.0 and 1.0a will have largely overlapping code
18:17:27 < Freeaqingme > Spabby, why would that be a problem?
18:17:38 < Spabby > Freeaqingme: I don't know about that if I'm honest, I defer to you knowledge
18:17:49 < Freeaqingme > 1.0 and 1.0a are largely the same
18:18:07 < Spabby > Freeaqingme: I think so, we will have some ZendService modules that are complete, some which are just an options file
18:18:13 < Spabby > may cause confusion in userland
18:18:15 < Freeaqingme > I'd rather have an adapter/factory pattern that uses an option class to determine what class to use
18:18:29 <weierophinney > so... what consensus do we have, if any? What I'm seeing here is that we may need an RFC for OAuth, since it's clearly a big domain. Thoughts?
18:18:37 < Spabby > have you seen the stuff in github Freeaqingme?
18:18:45 < Freeaqingme > Spabby, not in detail
18:19:00 < Mike_ZF2xMag > +1 for RFC
18:19:02 < Freeaqingme > (btw my apologies for my interruptions, thought I was talking in #zftalk.2)
18:19:09 < Spabby > just take a look at how the Options class works
18:19:14 < Freeaqingme > I'm +1 for rfc too
18:19:23 < DASPRiD > +1
18:19:26 < ezimuel > +1 for RFC, with the possibility to use as adapter of Zend\Auth, a module or a component
18:19:26 < Spabby > RFC is fine, I won't have time to do it until next week
18:19:38 < Freeaqingme > Spabby, I'll help
18:19:44 < DASPRiD > (mh, i should write a vote plugin for zend\bot, hehe)
18:19:46 < Spabby > unless mwillbanks or Freeaqingme want to take it
18:20:05 <ralphschindle > RFC +1
18:20:27 < EvanDotPro > it just seems strange to me to have some OAuth\Configuration namespace where we have like, Facebook, Google, Vimeo, Ohloh, Github, Myspace, Twitter, Flickr, Yahoo, Meetup, OpenSocial, Photobucket, etc, etc, etc, etc
18:20:36 < EvanDotPro > Spabby: ^^
18:20:47 < Spabby > EvanDotPro: I don't see a problem
18:20:58 < mwillbanks > Spabby: i'll see if i can find some time but i won't be sure till i get there
18:21:00 < ocramius > EvanDotPro: maybe they could live on a separate NS
18:21:10 <weierophinney > EvanDotPro: part of it is making it easy for developers to identify the path they need to take to make things work.
18:21:10 < ocramius > OAuh\Util\Config\WhateverBook
18:21:30 <weierophinney > having service-specific options classes makes sense to me.
18:21:32 < Freeaqingme > seems like there's consensus for an RFC. Spabby mwillbanks: I'll draft something up so we have something to discuss if you guys are okay with that
18:21:44 < Spabby > it would be "wow" when you could just create new OAuth(new Vendor\Github\Options());
18:21:55 <weierophinney > cool, thanks, Freeaqingme, for taking on the initial rfc work.
18:21:55 < Spabby > Freeaqingme: perfect
18:22:02 < Mike_ZF2xMag > weierophinney: further, developers attracted into the framework must find its components "logical", rather than having to hunt
18:22:02 < Spabby > thanks
18:22:03 < EvanDotPro > i'm +1 for an RFC.. i'd like to see the larger picture before getting too opinionated
18:22:06 <weierophinney > Spabby: +1! that looks cool.
18:22:17 < Spabby > weierophinney: that's how it works at the moment
18:22:21 <weierophinney > nice
18:22:24 <weierophinney > kk, next topic
18:22:32 < mwillbanks > Freeaqingme: go for it
18:22:36 <weierophinney > Zend\Math RFC and, tangentially, Zend\Crypt
18:22:39 < Spabby > 1 second, for those who haven't seen it git repo is here: https://github.com/Spabby/ZendService-OAuth2
18:22:41 < Spabby > I'm spent
18:22:55 <weierophinney > ezimuel: you have the floor
18:23:02 < ezimuel > ok, thanks
18:23:08 <weierophinney > (math rfc is here: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Math)
18:23:25 < ezimuel > the basic idea is to refactor Zend\Crypt\Math in Zend\Math
18:23:41 < ezimuel > and add all the math stuff in Zend\Math
18:24:13 < ezimuel > that means we have to refactor all the usage of Math classes to Zend\Math, in the RFC is reported some example
18:24:45 < ezimuel > right now the Zend\Crypt\Math contains only BigInteger components
18:25:23 < ocramius > ezimuel: reading from the wiki... Why would something like Haversine not fit?
18:25:29 < ezimuel > the question is: do you agree to split the Zend\Crypt\Math in Zend\Math ?
18:26:19 < ezimuel > ocramius: formulas are fine, so Haversine fit perfectly
18:26:24 < Mike_ZF2xMag > What taxonomy do you wish to derive in Zend/Math?
18:26:25 < ocramius > ezimuel: I'd surely move all the math stuff in Zend\Math if there is any possible usage for it... (not that I'm gonna use it, please keep me away from math )
18:26:45 < ocramius > for example, a hashing algorithm probably doesn't fit math
18:26:46 < ezimuel > ocramius: ahaha
18:26:51 < ocramius > while collisions probability could
18:27:06 < ezimuel > an hash algorithm uses Zend\;ath
18:27:10 < ocramius > I really don't know what is in Zend\Crypt\Math now
18:27:11 < ezimuel > sorry Zend\Math
18:27:31 < ezimuel > ocramius: right now is for the management of big integers
18:27:45 < ocramius > yes, I see
18:27:51 <weierophinney > I'm happy with moving math classes to Zend\Math. IIRC, the main reason we have them outside is that they were developed specifically for given consumers (openid, crypt). As long as those consumers can use the functionality, it's good; worst case scenario, they extend and wrap the functionality.
18:27:53 < ocramius > +1 for moving that
18:28:26 <weierophinney > any other feedback/votes/concerns from people?
18:28:56 < ocramius > yes, one, but it is not about the Math sub ns
18:28:59 < Mike_ZF2xMag > I'm wondering where cryptography will end up
18:29:16 < Mike_ZF2xMag > Zend/Math/Crypt namespace?
18:29:18 < ocramius > ezimuel: your current interface for encrypting and decrypting considers parameters
18:29:26 < ocramius > Mike_ZF2xMag: I would keep Zend\Crypt
18:29:39 < ocramius > ezimuel: I wish it was just a bit simplified
18:29:57 < Mike_ZF2xMag > ocramius: I /think/ I agree
18:29:58 < ezimuel > ocramius: i'm trying to write simple API for encrypt and decrypt
18:30:03 < ocramius > ezimuel: most of the time, the usage is $someEncryptorDecryptor->configure($stuff)
18:30:18 < ocramius > $someencr...->enc($data) or ->dec($data)
18:30:26 < ocramius > I wish all other params gone if possible
18:30:26 < ezimuel > ocramius: something like encrypt($data, $key)
18:30:34 < ocramius > ezimuel: yes
18:30:43 < ezimuel > ocramius: all the other params are optional
18:30:44 < ocramius > ezimuel: keeping the number of params as small as possible
18:31:01 < ezimuel > ocramius: i will do
18:31:03 < ocramius > ezimuel: not sure if the key hould be also optional
18:31:08 < ocramius > ezimuel: that could be part of the config
18:31:28 < ezimuel > ocramius: the key is the core concept in cryptography
18:31:33 < ocramius > yes
18:31:50 < ocramius > but sharing a key across, let's say, controllers
18:31:51 < ocramius > meh
18:32:03 < ocramius > I'd prefer to have some adapter configured to work with the key
18:32:09 < ocramius > in a single point
18:32:15 < ocramius > just my preference, heh
18:32:26 < ezimuel > ocramius: good point, I will think about it
18:32:53 < ocramius > nice
18:33:12 < ocramius > so if you can reduce it to encrypt($data) and decrypt($data) as minimum requirement it would be awesome
18:33:57 < ocramius > for the rest I am completely unaware of this math world and hopefully I won't have much to do with it
18:34:29 < ezimuel > ok, vote for Zend\Math ?
18:34:32 < ezimuel > +1
18:34:37 < Freeaqingme > (I'm leaving the discussion and as such not voting. back to work.. )
18:34:51 < Bittarman > +1
18:34:51 < EvanDotPro > +1 for Zend\Math
18:34:58 < ocramius > +1
18:34:58 < DeNix2000 > +1
18:34:58 <weierophinney > +1
18:35:23 < Mike_ZF2xMag > Mike_ZF2xMag: abstains
18:35:31 <ralphschindle > +1
18:36:03 <weierophinney > kk, last item. And it's not on the agenda, but was suggested a few times in the past weeks.
18:36:20 <weierophinney > Now that we're in DST, do we want to move the meeting time back 1h?
18:36:31 < Mike_ZF2xMag > +1
18:36:35 < Bittarman > +1
18:36:37 < ezimuel > +1
18:36:37 < ocramius > yes, indeed
18:36:39 < ocramius > +1
18:36:42 < ocramius > +2
18:36:44 < ocramius >
18:36:50 < EvanDotPro > i'll give a +1 even though i'm exempt from DST
18:36:57 <weierophinney > EvanDotPro: you don't count.
18:36:59 < ezimuel > ocramius: actually +4
18:37:19 <weierophinney > no binary addition, please.
18:37:23 < ocramius > I've already missed 2 or 3 meetings because of getting home from work
18:37:52 < EvanDotPro > ocramius: leave earlier... clearly zf2 meetings are far more important than any career.
18:37:57 <weierophinney > DASPRiD: dmitrybelyakov Freeaqingme hhatfield kobsu mwillbanks ralphschindler Spabby SpiffyJr_ wilmoore ....
18:38:00 <weierophinney > any thoughts, folks?
18:38:05 < mwillbanks > whoa!
18:38:05 < ocramius > EvanDotPro: can't, not always driving
18:38:13 < DASPRiD > weierophinney, ?
18:38:16 < DASPRiD > sorry have been afk
18:38:20 < mwillbanks > weierophinney: +1
18:38:24 <ralphschindle > i was plus 1 above ^
18:38:29 <weierophinney > DASPRiD: thoughts on moving meeting time back an hour?
18:38:30 < Freeaqingme > 'moving back' = earlier?
18:38:32 < SpiffyJr_ > +1, keeping them noon is probably best for me too
18:38:34 < mwillbanks > 1pm is a bit difficult
18:38:35 < ocramius > EvanDotPro: otherwise I'd love to leave earlier
18:38:37 <weierophinney > Freeaqingme: yes, one hour earlier.
18:38:39 < DASPRiD > weierophinney, uhm, so one hour earlier?
18:38:41 < DASPRiD > mhhh
18:38:48 <weierophinney > aka, 17:00 UTC
18:38:57 < DASPRiD > but only for DST, right?
18:38:57 < Freeaqingme > +1
18:38:57 <ralphschindle > oh, different question
18:39:02 <ralphschindle > I'm still +1
18:39:04 <weierophinney > DASPRiD: yes.
18:39:16 < DASPRiD > weierophinney, mh okay
18:39:17 <weierophinney > we moved the meetings forward to 18:00 UTC when DST ended last year.
18:39:24 <weierophinney > ralphschindler: yes?
18:39:26 < Spabby > +1
18:39:28 < Mike_ZF2xMag > Seems like everyone wants to go forward an hour, not back
18:39:48 <ralphschindle > im more or less with the community whichever way they chose to go, at 12 or 1, its all the same to me
18:39:50 <weierophinney > Mike_ZF2xMag: LOL
18:39:56 < EvanDotPro > lol Mike_ZF2xMag
18:39:57 < Mike_ZF2xMag >
18:40:04 <weierophinney > took me a moment there.
18:40:07 < ocramius > Mike_ZF2xMag: one hour later would be good for me, that means 21:00, which means I've started doing interesting stuff
18:40:11 <weierophinney > ralphschindler: you had a question?
18:40:32 <ralphschindle > no, i was referring to the fact that the question had changed
18:40:35 < ocramius > meh, I guess I missed the joke if there was
18:41:05 < EvanDotPro > weierophinney: you know, really my vote should count 2x here.. for everyone else this is about keeping the meeting time the same as it was, for me it's about actually changing the meeting time.
18:41:39 < Spabby > with your sleeping pattern you vote should count half
18:42:05 <weierophinney > Spabby: +1
18:42:06 <weierophinney >
18:42:06 < EvanDotPro > (regardless, i'm still +1, not that we're close to a swing vote or anything.)
18:42:21 <weierophinney > kk, I'll announce the time change on the list, then.
18:42:26 < Freeaqingme > Id say there's 50%+1 votes
18:42:45 < ocramius > who were the people involved in oauth then? Freeaqingme, mwillbanks and Spabby ?
18:42:52 < ocramius > just to know
18:42:53 <weierophinney > ocramius: correct.
18:43:01 < ocramius > thx
18:43:03 < mwillbanks > ocramius: yes; but Spabby has been leading the charge
18:43:05 < Spabby > everyone in zftalk.2
18:43:08 <weierophinney > So, some updates, while you're here and we have time to spare.
18:43:18 < mwillbanks > yay updates!
18:43:37 <weierophinney > Forms: I'm just about done with the InputFilter – working on the factory now and should finish that today. The rest is easy stuff.
18:43:56 <weierophinney > ServiceLocator nee InstanceManager: ralphschindler and I prototyped it this past week.
18:44:09 <weierophinney > ralphschindler did the hard work, and then I integrated it into the skeleton app
18:44:34 < ocramius > aha
18:44:37 <weierophinney > The good news: simpler configuration, simpler index.php. Bad news: we'll need to get that ServiceLocator RFC approved by next week.
18:44:49 < ocramius > is it in master or still on your branches?
18:45:00 <weierophinney > ezimuel completed Log, and also the JSON and YAML config adapters, and they're now in master.
18:45:06 < EvanDotPro > ocramius: in their branches.
18:45:08 < ocramius > ok
18:45:12 < Akrabat > can you post branch info to contributors?
18:45:13 <weierophinney > ocramius: still in branches. We'll drop an email today on th e contrib list about it.
18:45:14 <ralphschindle > branches, in fact, the ideal place to examine it is inside weierophinney's skeleton branch
18:45:18 <weierophinney > Akrabat: yes
18:45:31 < ocramius > ok, will do
18:45:35 <weierophinney > Akrabat: btw, we voted to do meetings 1h earlier.
18:45:43 < Akrabat > gah!
18:45:45 < Akrabat > oh well
18:46:07 < Akrabat > I trust you lot
18:46:11 <weierophinney > maybe we need a bigger vote than just the channel.
18:46:23 <weierophinney > we need some CR team folks here to reign me in.
18:46:33 < Akrabat > LOL
18:46:37 < wilmoore > weierophinney: sorry, I just got back in from lunch
18:46:43 < Akrabat > loosely, I can't do 5pm -> 7pm my time
18:46:50 <weierophinney > Last item: ralphschindler also got a bunch of DB stuff merged to master this week, so if you had issues before, pull and see if they're fixed.
18:46:54 <weierophinney > Akrabat: aha
18:47:03 <weierophinney > Akrabat: I'll initiate a poll, then.
18:47:16 <weierophinney > perhaps an hour later makes more sense.
18:47:36 < Freeaqingme > weierophinney, that would make sense as well. but perhaps should be discussed on the ml
18:47:43 <weierophinney > so, that's it for updates for now. Was hoping Thinkscape would be here to discuss Console progress, but oh well.
18:47:48 * EvanDotPro grumbles about that overlapping his 1200 nap.
18:47:48 < Freeaqingme > people who cant attend this time, may be likely to be able to be here 2 hrs later
18:47:54 <weierophinney > Freeaqingme: yep – as I said, I'll initiate a poll.
18:48:10 <weierophinney > EvanDotPro: LOL
18:48:10 < Akrabat > 7:30pm BST works well for me
18:48:13 < Freeaqingme > EvanDotPro, I some times skip a night. Can imagine it being easy to skip just 30 mins
18:48:28 <weierophinney > kk, meeting is over. I'll get the log up later today.
18:48:31 <weierophinney > thanks, everyone!