View Source

<ac:macro ac:name="toc" />

<h2>Information</h2>

<ul>
<li>Date: 28 March 2012, 18:00-19:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-03-28 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 04 April 2012</li>
</ul>


<h2>Summary</h2>

<h3>Service Components RFC</h3>

<p>(Search for &quot;18:03:37&quot; in the log.)</p>

<p>Mike Willbanks (mwillbanks) created an <ac:link><ri:page ri:content-title="RFC - Service Components" /><ac:link-body>RFC for Service Components</ac:link-body></ac:link>, which discusses moving the various <code>Zend\Service</code> components into separate repositories. This allows:</p>

<ul>
<li>Shipping them individually</li>
<li>Versioning them separately from the framework, which in turn allows keeping them up-to-date with API changes separate from the framework release cycle.</li>
<li>Reducing maintenance overhead of the principal framework components.</li>
</ul>


<p>Discussion mainly centered around the principal namespace for these components, as well as packaging. In the end, consensus appeared to be for using &quot;ZendService&quot; as the root namespace, and for each service type to have its own repository under the zendframework Github organization. This also facilitates easy enabling of Composer for distribution, while allowing for a relatively easy way to package for the Pyrus channel at packages.zendframework.com.</p>

<p>At the end of the discussion, we voted to approve the RFC.</p>

<p><strong>tl;dr</strong>: Most <code>Zend\Service</code> components will get a new life in separate repositories under the zendframework organization, using the top-level namespace &quot;ZendService&quot;.</p>

<h3>Cache return values</h3>

<p>(Search for &quot;18:22:20&quot; in the log.)</p>

<p>Marc Bennewitz (_mabe) added an item to the agenda, asking how <code>Zend\Cache</code> should return cache &quot;misses&quot;. Traditionally, a boolean <code>false</code> or a <code>null</code> return value can indicate this, but <code>Zend\Cache</code> should really formalize it to make it predictable. This is compounded by the fact that such values might be <em>intentional</em>, however.</p>

<p>Between Marc and others, the following solutions were suggested:</p>

<ul>
<li>Missing value -&gt; mark error -&gt; return false</li>
<li>Missing value -&gt; return null</li>
<li>Return a CacheItem object, with methods to determine status of request (<code>isMiss()</code>, <code>isHit()</code>, etc.)</li>
<li>Have an optional reference boolean argument for indicating cache hit or miss</li>
</ul>


<p>The latter was deemed the more performant and easy to implement, and this along with returning <code>null</code> on cache miss was voted as the appropriate solution. The only question at this point is where in the argument list to put the reference boolean argument; this will be taken to the list.</p>

<p><strong>tl;dr</strong>: A sensible, performant solution was chosen for what to return on cache misses.</p>

<h3>Zend\Crypt development</h3>

<p>(Search for &quot;18:35:10&quot; in the log.)</p>

<p>Enrico Zimuel (ezimuel) posted an agenda item with a list of work he plans for <code>Zend\Crypt</code>, including a variety of encrypted authentication methods, improving cryptographic randomness, bcrypt support, and support for string, file, and stream cryptographic functionality. This will also allow us to centralize all cryptographic functionality in a single component, instead of implemented in each component requiring it.</p>

<p>There were a number of questions, in particular:</p>

<ul>
<li>What interfaces will be provided, and which can be implemented to create/implement new algorithms?</li>
<li>Why are auth and encryption condensed into single methods rather than chains?</li>
</ul>


<p>Overall, those present really like the ideas, but need some background to fully understand and appreciate what Enrico proposes. We decided Enrico should write up an RFC detailing the exact changes he intends, with discussion of the design decisions he's making.</p>

<p><strong>tl;dr</strong>: Enrico has some excellent ideas for <code>Zend\Crypt</code>, and will be creating an RFC soon.</p>

<h2>Log</h2>

<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
<style>
pre.log {
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;
padding: 0.5em;
}
</style>
<pre class="log">
18:03:28 &lt;weierophinney &gt; let's get started
18:03:37 &lt;weierophinney &gt; First up: Service components RFC
18:03:43 &lt;weierophinney &gt; mwillbanks: you have the floor. :)
18:03:51 &lt; mwillbanks &gt; alright thanks
18:04:00 &lt;weierophinney &gt; reminder: RFC is here: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Service+Components
18:04:09 &lt; mwillbanks &gt; service components RFC; if you haven't read it... do it now
18:04:33 &lt; mwillbanks &gt; basics: remove Zend\Service from the core of the framework and provide them through more or less a package repo
18:04:48 &lt; mwillbanks &gt; pyrus w/ composer bridge or otherwise...
18:05:08 &lt; mwillbanks &gt; main goal is so that services can be versioned independently of the framework so API changes can be quickly addressed
18:05:45 &lt; mwillbanks &gt; most feedback on the RFC centered around if they should be modules or components; i believe strongly that they should stay components of the library
18:05:52 &lt;weierophinney &gt; mwillbanks: my only "real" question on this is with the requirement that they be in their own namespace. What is your suggestion for naming the various service components?
18:06:18 &lt;weierophinney &gt; mwillbanks: I'm agreed with you on component vs module; this is library code, not MVC code.
18:06:48 &lt; mwillbanks &gt; weierophinney: something to the degree of ZendService\Amazon or ZendS\Amazon etc; basically follow the same area that the Zend namespace does
18:07:03 &lt;weierophinney &gt; ah, okay
18:07:04 &lt; mwillbanks &gt; it seems that it would work out better to speak to the degree of separation from the core
18:07:12 &lt;weierophinney &gt; I'd vote for ZendService as the "vendor" namespace.
18:07:25 &lt; ezimuel &gt; why not Zend\ExternalService\* ?
18:07:28 &lt;weierophinney &gt; retains a semantic link to previous versioning.
18:07:31 &lt;weierophinney &gt; ezimuel: too verbose. :)
18:07:42 &lt; Spabby &gt; can they stay in Zend\Service?
18:07:57 &lt;weierophinney &gt; ezimuel: also, I'd expect anything under the 'Zend' namespace to be something within the main ZF repo.
18:07:57 &lt; ezimuel &gt; Zend\ExtService\* ?
18:08:16 &lt; mwillbanks &gt; weierophinney: exactly my thoughts
18:08:16 &lt;weierophinney &gt; So having the top-level namespace have our "vendor" as a prefix makes sense.
18:08:19 &lt; rdohms &gt; well i guess we need to keep zend in the name.. otherwise theuy are loose
18:08:30 &lt; mwillbanks &gt; previously there was ZendX
18:08:35 &lt; rdohms &gt; Zend\Service sounds good.. i like External.. but i agree its too verbose
18:08:35 &lt;weierophinney &gt; rdohms: I'd keep Zend in the name simply as we're the "vendor" here.
18:08:50 &lt;dmitrybelyako &gt; ezimuel Zend\Service\* may be defficult for composer as they do Vendor\Package, so ZendService\* would be fine with composer
18:08:57 &lt;weierophinney &gt; i.e., it falls in the ZendFramework organization.
18:09:04 &lt;weierophinney &gt; dmitrybelyakov: good point.
18:09:11 &lt; Spabby &gt; I think the namespace is dependant on some other decisions though, if they are going to be optional, ie not included in "core" maybe we should have a more generic namespace for other things that might be included in that scope
18:09:22 &lt; ezimuel &gt; dmitrybelyakov : that's true
18:09:27 &lt; Spabby &gt; so ZendExtra rather or similar rather than ZendService
18:09:53 &lt; Freeaqingme &gt; I ran in late, read up, and may have missed a bit. What's wrong with ZendService\?
18:09:56 &lt; mwillbanks &gt; Spabby: that is a good point; and one that I attempted to make in the RFC; that I would hope that this infrastructure decision could eventually lead us down the path of having ZendModule or otherwise
18:09:58 &lt; Freeaqingme &gt; to me, that would make most sense
18:10:02 &lt;weierophinney &gt; Spabby: I'd agree with that for non-service compnents. That's what ZendX was kind of about previously. I think the infrastructure in ZF1 didn't suit it as well, but with Git, pyrus, composer, etc, it's easier to do.
18:10:08 &lt;weierophinney &gt; Freeaqingme: nothing. :)
18:10:31 &lt; rdohms &gt; dmitrybelyakov: tha tis just pakcage name in composer... it can have any name.. dpoes not need to match namespace
18:10:35 &lt; mwillbanks &gt; however, speaking specifically here; ZendService namespace is really to speak exactly about services and how to move them outside of the core
18:10:50 &lt; mabe_ &gt; Than ZendX for all non core components
18:11:13 &lt; mwillbanks &gt; I also believe that having them in a "Zend" namespace could cause confusion for say sysadmins or even folks using the framework to understand that the component may not be bundled with the framework
18:11:14 &lt;weierophinney &gt; mwillbanks: regarding distribution, because these would each have their own repo, composer can happen easily, with no effort other than composer.json files. We'd need to add a little bit to our packaging script for pyrus, but that's do-able. Basically, I'm saying we can offer both.
18:11:33 &lt;weierophinney &gt; mwillbanks: the only caveat is that dependencies on ZF components would be harder until we solve that issue.
18:11:36 &lt; mwillbanks &gt; weierophinney: and that was exactly my thoughts about making a single packaging script
18:11:47 &lt; Spabby &gt; mwillbanks: this discussion is directed towards services, but it wouldn't hurt to look at the wider picture when making a namespace decision
18:11:53 &lt;dmitrybelyako &gt; rdohms guess it's a good idea to make package name = namespace
18:12:15 &lt; mwillbanks &gt; Spabby: true; however, it is also important to recognize that we could easily add new namespaces in the future for other things
18:12:30 &lt; Spabby &gt; in which case +1 for ZendService
18:12:37 &lt; Freeaqingme &gt; just throwing it out there, shouldnt we put all core components in zend\core\, like zend\core\mvc? So we can leave the services part for zend\service ?
18:12:55 &lt; Freeaqingme &gt; that would allow us to still use one single root namespace
18:13:00 &lt; mwillbanks &gt; Freeaqingme: so then we'd be typing Zend\Core\Mvc\Controller\ActionController?
18:13:01 &lt; rdohms &gt; dmitrybelyakov: does not make a diffene in this case: zend/service-amazon zend/service-joindin
18:13:10 &lt;weierophinney &gt; Freeaqingme: I'm not sure what we gain from that.
18:13:19 &lt; Freeaqingme &gt; mwillbanks, nah, usually you would put that in a use statement ;)
18:13:20 &lt; rdohms &gt; the pckage names are just labels in most cases
18:13:54 &lt; Freeaqingme &gt; weierophinney, the gain would be that we retain one single root namepace. Helps us be recognizable, same reasoning why we didnt go for ZendTest\
18:13:55 &lt;weierophinney &gt; mwillbanks: each component would be in a separate repo, under the zendframework organization, correct?
18:14:04 &lt; mwillbanks &gt; weierophinney: yes
18:14:16 &lt;weierophinney &gt; Freeaqingme: well, the "zend" namespace is for the framework. We're moving services out.
18:14:19 &lt;weierophinney &gt; mwillbanks: cool
18:14:35 &lt; mwillbanks &gt; weierophinney: unless for other reasons you would prefer to have them under say an org like zf-services... but i don't really see a huge point in that :)
18:14:55 &lt;weierophinney &gt; no, I think this is good -- was really just making sure they'd each have their own repo. :)
18:15:09 &lt; SocalNick &gt; Sorry if this was already covered, but is the proposed Service library different than the libraries in ZF-Commons?
18:15:20 &lt; Freeaqingme &gt; weierophinney, I'm thinking I may be alone in this ;)
18:15:22 &lt; Freeaqingme &gt; so nvm
18:15:23 &lt; mwillbanks &gt; SocalNick: currently ZF-Commons contains mostly modules
18:15:50 &lt; mwillbanks &gt; ZF-Commons has a slightly different function and could more or less be seen as an official module area
18:15:50 &lt; SocalNick &gt; mwillbanks - i've been looking at modules as if they could be simply libraries
18:15:52 &lt;weierophinney &gt; SocalNick: this is to move the various Zend\Service\* components out of the main framework, basically. Also, ZF-Commons is mostly focussed on MVC modules at this time, and less on library-style code.
18:16:02 &lt; SocalNick &gt; gotcha
18:16:06 &lt; Spabby &gt; read the RFC ;)
18:16:09 &lt; ezimuel &gt; so why don't ship as packages outside the core and leave the Zend\Service name?
18:16:26 &lt; mwillbanks &gt; ezimuel: the release cycle could be problematic
18:16:32 &lt;weierophinney &gt; SocalNick: modules _can_ be libraries. But that makes most sense when the library needs to tie into the MVC or application lifecycle.
18:16:43 &lt; ezimuel &gt; mwillbanks: why?
18:16:43 &lt; mwillbanks &gt; ezimuel: if you remember back in some of the ZF1 days there was a change to the amazon api which rushed a ZF release
18:17:09 &lt; Spabby &gt; we don't want to have a broken service component until next point release
18:17:12 &lt; mwillbanks &gt; ezimuel: api's are always changing for each vendor and it doesn't make sense to have them tied to large releases for smaller fixes
18:17:16 &lt;weierophinney &gt; ezimuel: also, confusion as to where it lives -- using the Zend\ top-level namespace implies it's a part of the main distribution, not a separate repo.
18:17:17 &lt; ezimuel &gt; yesm but if we manage versioning of service this will manage the issue
18:17:27 &lt; Freeaqingme &gt; we should limit the amount of root namespaces though, that would improve autoloading me thinks
18:17:33 &lt; ezimuel &gt; I mean just for Zend\Service\* components
18:17:38 &lt; ocramius &gt; re
18:17:52 &lt;weierophinney &gt; ezimuel: see above -- it's easier to manage these outside the framework versioning lifecycle as well.
18:18:14 &lt; ocramius &gt; can someone just tell me where you got? :)
18:18:26 &lt;weierophinney &gt; ocramius: we're finishing up the Services RFC discussion.
18:18:34 &lt;weierophinney &gt; Speaking of... we're hitting the time limit.
18:18:36 &lt; mwillbanks &gt; in terms of packaging is everyone fine with using composer and then building packages for packages.zendframework.com ?
18:18:43 &lt;weierophinney &gt; I move that we vote.
18:18:50 &lt; mwillbanks &gt; yay vote!
18:18:50 &lt;weierophinney &gt; mwillbanks: I'm fine with both, yes.
18:18:52 &lt; rdohms &gt; mwillbanks: +1
18:18:55 &lt;weierophinney &gt; +1
18:19:00 &lt; ocramius &gt; +1
18:19:01 &lt; mwillbanks &gt; +1 :D
18:19:06 &lt; mattcockayne &gt; +1
18:19:08 &lt; ezimuel &gt; +1
18:19:15 &lt; ocramius &gt; some guidelines/manual to do that could be needed
18:19:25 &lt; ocramius &gt; but maybe I'm just to n00b to know it :D
18:19:26 &lt;weierophinney &gt; ocramius: to do which?
18:19:35 &lt; ocramius &gt; packaging done right
18:19:43 &lt;weierophinney &gt; ocramius: ah, yeah -- we can make that easy.
18:19:50 &lt; MikeA_ &gt; I like the idea of ZendService because it shows Zend following a separation approach that module developers are going to have to follow when modules abound and module-sets have to rely on many intra and extra module components
18:20:12 &lt; MikeA_ &gt; It's a good psychological lead, as well as a technical one of course
18:20:26 &lt;weierophinney &gt; for those abstaining from voting -- do any of you have concerns you feel are not being addressed?
18:20:31 &lt; MikeA_ &gt; mwillbanks: +1
18:20:32 &lt;weierophinney &gt; MikeA_: good points.
18:21:12 &lt; mwillbanks &gt; *silence* ...
18:21:12 &lt; Freeaqingme &gt; weierophinney, I am abstaining, but did mention my thoughts, which have been addressed
18:21:21 &lt;weierophinney &gt; kk
18:21:25 &lt;weierophinney &gt; So, let's move on.
18:21:30 &lt; Spabby_ &gt; I missed the vote sorry, my laptop died
18:21:31 &lt;weierophinney &gt; Next topic: Cache return values
18:21:32 &lt; ocramius &gt; did the ZendService thing renamed to InstanceManager settle?
18:21:49 &lt;weierophinney &gt; ocramius: ralphschindler will be dropping an email to the ML tomorrow.
18:21:54 &lt; ocramius &gt; ok
18:22:12 &lt;weierophinney &gt; ocramius: and that as ServiceLocator originally anyways. But yes, looking like switching names to make the purpose more clear.
18:22:16 &lt;weierophinney &gt; NEXT TOPIC
18:22:20 &lt;weierophinney &gt; Cache return values
18:22:31 &lt; mabe_ &gt; On cache return values there are questions what should we do on missing items
18:22:44 &lt; Freeaqingme &gt; is there an rfc?
18:22:56 &lt; mabe_ &gt; no
18:22:58 &lt;weierophinney &gt; Freeaqingme: no, just an item in the agenda
18:22:59 &lt;dmitrybelyako &gt; null is better imo
18:23:01 &lt; mabe_ &gt; return false, null or an result object
18:23:01 &lt; Bittarman &gt; mabe_, do what apc does, take an argument by reference.
18:23:11 &lt; Bittarman &gt; mabe_, the other option you didn't just mention :)
18:23:18 &lt;weierophinney &gt; so, four options now
18:23:26 &lt; ocramius &gt; mabe_: resultObject seems to be a bit heavy
18:23:28 &lt;weierophinney &gt; GROWING BY THE MINUTE! QUICK, CLEAN THE CACHE!
18:23:29 &lt; mabe_ &gt; but apc retuns false
18:23:35 &lt; Bittarman &gt; mabe_, no.
18:23:52 &lt; ocramius &gt; mabe_: I want null... null is the representation for "no value"
18:23:59 &lt; EvanDotPro &gt; null makes the most sense to me.
18:23:59 &lt;weierophinney &gt; ocramius: well, using a prototype pattern, it's not bad, and object creation/memory usage in 5.3 and 5.4 is really, really minimal.
18:24:01 &lt; Bittarman &gt; look at apc_fetch's arguments, it takes a second argument to explicitly state (boolean value) whether it was a hit or not.
18:24:07 &lt; Bittarman &gt; http://php.net/apc_fetch
18:24:10 &lt;weierophinney &gt; ocramius: my point with that is it solves a number of problems.
18:24:17 &lt; mabe_ &gt; ext/memcached-2 also changed the return value for it to null
18:24:21 &lt; Gabriel403 &gt; What did I miss
18:24:25 &lt; Bittarman &gt; hehe, and the train started moving.. may dissapear again now...
18:24:27 &lt; ocramius &gt; mabe_: yes, but cache is something the users tend to "bomb"
18:24:33 &lt; ocramius &gt; it is highly performance critical
18:24:33 &lt; Bittarman &gt; mixed apc_fetch ( mixed $key [, bool &$success ] )
18:24:33 &lt;weierophinney &gt; Bittarman: could that be abstracted to other adapters, though?
18:24:38 &lt; mwillbanks &gt; Bittarman: +1
18:24:55 &lt; Bittarman &gt; weierophinney, probably.
18:24:56 &lt;weierophinney &gt; ocramius: I think that last was directed at me, not mabe_ :)
18:25:07 &lt; Freeaqingme &gt; +1 for null, +1 for reference boolean
18:25:13 &lt; ocramius &gt; yeah, sry
18:25:16 &lt; Bittarman &gt; I guess how easy that is depends on the backend...
18:25:18 &lt; mwillbanks &gt; +1 for null, +1 for reference boolean
18:25:19 &lt; mwillbanks &gt; :D
18:25:30 &lt; mattcockayne &gt; +1 for null, +1 for reference boolean
18:25:43 &lt; mwillbanks &gt; the main issue is that sometimes you might want the null, false or otherwise... without the boolean reference it would be impossible to tell
18:25:48 &lt; mabe_ &gt; the reference shoudl than the second or the third arg
18:26:00 &lt; Spabby_ &gt; +1 for null, +1 for reference boolean
18:26:01 &lt; mabe_ &gt; we have an options array as second arg ;)
18:26:04 &lt;weierophinney &gt; mwillbanks: that was my point with the result objects, but a reference value might assist.
18:26:10 &lt; ocramius &gt; how would the boolean reference work?
18:26:15 &lt; Bittarman &gt; looks like most of the extensions provide something to allow references to work actually
18:26:17 &lt; ocramius &gt; store last result?
18:26:21 &lt; Bittarman &gt; http://uk.php.net/manual/en/memcached.get.php
18:26:22 &lt; mwillbanks &gt; weierophinney: i think that a reference object might just be "too" much
18:26:57 &lt;weierophinney &gt; mwillbanks: as I said, the reference boolean may solve it as well.
18:27:04 &lt;weierophinney &gt; mabe_: thoughts?
18:27:06 &lt; mabe_ &gt; getItem(string $key, array $options, & $seccess)
18:27:12 &lt; Freeaqingme &gt; ocramius, when retrieving something from cache, you could supply a 2nd argument which will be set to true/false if there's a hit
18:27:13 &lt; Bittarman &gt; http://uk.php.net/manual/en/memcache.get.php
18:27:14 &lt; ezimuel &gt; we can return null by default and if we a refence pass the reference
18:27:34 &lt; EvanDotPro &gt; so yeah, i'm +1 for null + a reference boolean to cover cases where null/false are valid cached responses.
18:27:42 &lt;weierophinney &gt; +1 here as well
18:27:42 &lt; Freeaqingme &gt; ohi EvanDotPro
18:27:47 &lt; ocramius &gt; Freeaqingme: byref?
18:27:50 &lt; EvanDotPro &gt; hey Freeaqingme :)
18:27:52 &lt; Bittarman &gt; sqlite is obvious.. result would be no rows :)
18:27:53 &lt; ocramius &gt; hmm
18:27:56 &lt; Freeaqingme &gt; mabe_, do you have any considerations? since you're mr cache?
18:28:12 &lt; mabe_ &gt; Freeaqingme ?
18:28:21 &lt; Freeaqingme &gt; Bittarman, difference is if you're retrieving a set of results, or just a single result
18:28:33 &lt; Bittarman &gt; hmm.. zend's cache extension isn't documented on php.net :)
18:28:43 &lt; Freeaqingme &gt; mabe_, how do you think about the returning null, and the reference arg?
18:28:56 &lt; Bittarman &gt; Freeaqingme, yeah, but in sqlite, there would be 0 results in the rowset vs a row with a column which is null
18:28:57 &lt; mabe_ &gt; zend data cache only returns false - no ref
18:28:59 &lt; ocramius &gt; mabe_: that interface doesn't really look cool... you would have to pass $options to be able to pass $success...
18:29:16 &lt; ocramius &gt; maybe swap params or use $options as ref?
18:29:17 &lt; Bittarman &gt; mabe_, maybe we should just tell zend to fix thier stuff :)
18:29:28 &lt; ocramius &gt; Bittarman: indeed
18:29:34 &lt; mabe_ &gt; i'm ok with reference - but we have an options array as optionsal argument - what should be the order ?
18:29:34 &lt; mattcockayne &gt; i though zends data cache was a drop in replacement for apc... surely it has the same param
18:29:55 &lt; ocramius &gt; mabe_: I am for $options containing it... or swap the params
18:29:57 &lt; mwillbanks &gt; Bittarman: yeah; zend data cache makes me angry... we have zend server but disable their data caching components lol
18:29:57 &lt; Bittarman &gt; ah, it can do it.
18:30:00 &lt;weierophinney &gt; mabe_: I think ocramius has a poitn -- if we add this arg, it should be the second argument, as it may be more common than passing options.
18:30:01 &lt; mabe_ &gt; getItem($key, $options, & $ref) | getItem($key, & $ref, $options) ??
18:30:22 &lt; Bittarman &gt; $cache-&gt;fetch(array('key' =&gt; $key)) will return an array, without a key 'key' if $key is not found.
18:30:27 &lt; Freeaqingme &gt; weierophinney, alternatively, if $options is not an array, but a bool, it could still be treated as the $isSuccess param
18:30:29 &lt; mabe_ &gt; yea $options can contain it
18:30:32 &lt;weierophinney &gt; ocramius: having options contain it is hard, as passing references within arrays is problematic
18:30:37 &lt; Bittarman &gt; so, zend data cache can be manipulated to work that way.
18:30:42 &lt; EvanDotPro &gt; my rule of thumb is that i order optional parameters by how often i anticipate them being used... in this case, the reference might be more common.
18:30:46 &lt; mattcockayne &gt; http://files.zend.com/help/Zend-Server-Community-Edition/zend_data_cache_-_php_api.htm
18:30:56 &lt;weierophinney &gt; mabe_: getItem($key, &$ref, $options = array())
18:30:57 &lt; ocramius &gt; weierophinney: yeah, I don't like references anyway, but it is really a question of microseconds
18:31:10 &lt; Freeaqingme &gt; EvanDotPro, yet, how often do you cache null? That's be the only usecase me thinks for that ref
18:31:15 &lt; mwillbanks &gt; i don't know if it should be the second argument... in general; you will likely not be expecting a null value from the cache, however, in special cases you will... so the reference seems far more special case than the options argument IMO
18:31:16 &lt;weierophinney &gt; mabe_: rather, getItem($key, &$ref = false, $options = array())
18:31:20 &lt; mabe_ &gt; Freeaqingme - than the complete options arg must be a ref
18:31:23 &lt; Bittarman &gt; yeah, don't do pass by reference with an array.
18:31:43 &lt; Freeaqingme &gt; aight, but this is quite specific. Perhaps we should just vote on the idea in general?
18:31:45 &lt;weierophinney &gt; ocramius: I wasn't even talking about performance, but the difficulty in getting it right and educating users. :)
18:31:46 &lt; EvanDotPro &gt; Freeaqingme: true -- i think both params will be _somewhat_ rare...
18:31:56 &lt; ocramius &gt; weierophinney: aah, k :D
18:32:13 &lt; mabe_ &gt; we already have a ref options -&gt; the token used for checkAndSet operations ;)
18:32:14 &lt;weierophinney &gt; mwillbanks: you bring up a good point as well.
18:32:22 &lt; ocramius &gt; weierophinney: this would be an edge-case feature anyway
18:32:35 &lt; ocramius &gt; weierophinney: as most users will just if($cache-&gt;get(...))
18:33:03 &lt; Gabriel403 &gt; I'm getting the idea we're discussing zend cache
18:33:04 &lt;weierophinney &gt; okay, so, It sounds like we're agreeing that we should allow passing a boolean reference variable to getItem() to allow distinguishing if we had a cache hit or not.
18:33:06 &lt; Freeaqingme &gt; yeah, as said, you'll rarely cache null. Yet, Im not sure if we should discuss this api so specifically. rather than just vote on it
18:33:15 &lt; EvanDotPro &gt; 99% of the time i see myself passing key only, so my opinion on this is really not very strong at all, heh.
18:33:16 &lt; ezimuel &gt; ocramius: I agree false or null are not usual values to cache
18:33:16 &lt;weierophinney &gt; The remaining question is where in the signature to put it.
18:33:30 &lt;weierophinney &gt; I think we can take this to the list at this point if further discussion is needed.
18:33:35 &lt;weierophinney &gt; Does that sound like a good summary?
18:33:40 &lt; Freeaqingme &gt; weierophinney, with the addendum that the opinion is to return null if no value is found
18:33:41 &lt; mwillbanks &gt; yes
18:33:52 &lt;weierophinney &gt; Freeaqingme: right -- sorry I missed that.
18:34:02 &lt;weierophinney &gt; mabe_: are you satisfied?
18:34:23 &lt;weierophinney &gt; going once...
18:34:35 &lt; mabe_ &gt; weierophinney, yea +1 for boolean reference + ML for signiture
18:34:48 &lt;weierophinney &gt; cool, thx!
18:35:10 &lt;weierophinney &gt; Last topic: Zend\Crypt features. This is only in the agenda, but has also had some ML discussion already.
18:35:25 &lt;weierophinney &gt; I direct all feedback/questions/abuse to ezimuel at this point. :)
18:35:30 &lt;weierophinney &gt; ezimuel: you have the floor. :)
18:35:31 &lt; Xerkus &gt; is it valid use case if we have outdated cache: getItem($key, &$ref, array('allowOutdated' =&gt; true)); will return data but set $ref to false?
18:35:36 &lt; ocramius &gt; spit it out ezimuel :D
18:35:40 &lt; ezimuel &gt; thanks
18:35:54 &lt; ezimuel &gt; the idea is to add some features to Zend\Crypt basically:
18:36:01 &lt; ezimuel &gt; add the encrypt/decrypt methods to Zend\Crypt using the simmetric algorithms of Mcrypt
18:36:06 &lt; Xerkus &gt; looks like i'm too late
18:36:07 &lt; Freeaqingme &gt; (what's the url of the agenda? wiki search has no results...)
18:36:11 &lt; Guest68955 &gt; @nickserv
18:36:11 &lt; ezimuel &gt; add the encryptThenAuth, AuthThenEncrypt, encryptAndAuth methods to Zend\Crypt, to implement a secure encryption + authentication schema
18:36:26 &lt; ezimuel &gt; add the encryptThenAuth, AuthThenEncrypt, encryptAndAuth methods to Zend\Crypt, to implement a secure encryption + authentication schema
18:36:27 &lt; Gabriel403 &gt; http://framework.zend.com/wiki/display/ZFDEV2/2012-03-28+Meeting+Agenda
18:36:33 &lt; ezimuel &gt; improve the randomness of Zend\Crypt\Math::rand
18:36:38 &lt; mabe_ &gt; Xerkus: you can get expired data by set a ttl of 0
18:36:40 &lt; ocramius &gt; Xerkus: strange case, you could ask mabe_ later I guess
18:37:01 &lt;weierophinney &gt; Freeaqingme: http://framework.zend.com/wiki/display/ZFDEV2/2012-03-28+Meeting+Agenda
18:37:07 &lt; Freeaqingme &gt; weierophinney, Gabriel403 tnx
18:37:12 &lt; ezimuel &gt; adding these features we will have a simple API to encrypt/decrypt string/file/stream
18:37:28 &lt; Bittarman &gt; ezimuel, sounds nice to me.
18:37:30 &lt; ezimuel &gt; and to store password in a secure way using the bcrypt algorithm
18:37:48 &lt; Bittarman &gt; somebody was in zftalk asking for a secure token generation routine today also.
18:37:52 &lt;weierophinney &gt; ... and allow us to move crypt features into a single location instead of spread out amongst several components...
18:37:54 &lt; Freeaqingme &gt; ezimuel, it's been a while that this has been discussed. Why would we want to combine encrypt() and auth() ? to 1 method?
18:38:07 &lt; ocramius &gt; ezimuel: didn't watch Zend\Crypt in detail, but I would really love to have an interface that is used as dependency
18:38:13 &lt; ocramius &gt; encryption/decryption service
18:38:28 &lt; ezimuel &gt; Freeaqingme: because this is the secure way to store information
18:38:42 &lt; Freeaqingme &gt; ezimuel, but, why would someone just not chain them?
18:39:16 &lt; ezimuel &gt; Freeaqingme: because there are some differences, is not a simple chain
18:39:49 &lt; MikeA_ &gt; Freeaqingme: developers new to ZF2 will find it eaier if all crypography components are in one place
18:39:53 &lt;weierophinney &gt; ezimuel: perhaps you can write that up to the ML -- detail why this is the case?
18:39:59 &lt; ocramius &gt; indeed
18:40:02 &lt; Freeaqingme &gt; ezimuel, I cant recall the exact discussion. but I'm all for moving it into one component (not 1 class per se, obviously)
18:40:14 * weierophinn understands, but it's hard to explain in IRC
18:40:40 &lt; ezimuel &gt; weierophinney: yes, maybe an RFC is better to explain, with some details
18:40:50 &lt; mabe_ &gt; Does crypt also mean hash algos ?
18:40:53 &lt; Gabriel403 &gt; +1 for rfc
18:41:09 &lt; ezimuel &gt; Crypt uses hash algo for authentication
18:41:13 &lt;weierophinney &gt; ezimuel: +1 for RFC -- I think you know the needs well, but it's good to detail the decisions.
18:41:19 &lt; Bittarman &gt; mabe_, ezimuel just mentioned using bcrypt for that, so yes
18:41:42 &lt; ocramius &gt; ezimuel: please remember the service thing... I will personally (probably) never look into algorithms themselves, but surely would like a simple interface that can be used in two directions to hash/encrypt/decrypt
18:41:47 &lt; ezimuel &gt; weierophinney: ok, I will write the RFC with all the details and the class schema
18:41:55 &lt; mwillbanks &gt; +1
18:42:27 &lt; ezimuel &gt; ocramius: that's the idea: make the cryptography simple using ZF2 (and we will be the first PHP framework that have this component)
18:42:34 &lt; Freeaqingme &gt; ezimuel, would be appreciated if in any such rfc you could outline why encrypt() and auth() couldnt just be chained
18:42:36 &lt;weierophinney &gt; Overall, though, looks like lots of support for this idea, ezimuel :)
18:42:37 &lt; EvanDotPro &gt; i'm +1 ... it would be nice to have a common place to point those knuckleheads who are making their own "user" modules to at least make sure they're implemeting secure bcrypt hashing instead of something like sha1('$@lt' . $password).
18:42:48 &lt; mwillbanks &gt; aka EvanDotPro :p
18:42:57 &lt; ezimuel &gt; Freeaqingme: yes, I will do
18:43:08 * mwillbanks chuckles and waits for a stapler to find its way through the air
18:43:09 &lt; ocramius &gt; EvanDotPro: public function encrypt($str) {return $str;
18:43:13 &lt; ocramius &gt; at least it's fast
18:43:18 &lt; Gabriel403 &gt; EvanDotPro: ey how did you get our salt?!?
18:43:34 &lt; EvanDotPro &gt; lol
18:43:46 &lt;weierophinney &gt; cool!
18:43:54 &lt; Lars___ &gt; lol
18:43:56 &lt;weierophinney &gt; So, any further discussion here?
18:44:08 &lt; ocramius &gt; wasn't there already some RFC about it?
18:44:08 &lt;weierophinney &gt; If not, I vote we close early for once, and build cool stuff. :)
18:44:15 &lt;weierophinney &gt; ocramius: not yet.
18:44:18 &lt; ocramius &gt; ok
18:44:19 &lt; EvanDotPro &gt; i also like this because i already implemented a basic abstraction for bcrypt in ZfcUser and i'd love to just use a framework component instead.
18:44:24 &lt;weierophinney &gt; ocramius: hence, the votes for having an RFC. :)
18:44:30 &lt; Spabby_ &gt; anyone wanting to look at oauth look at the crappy rfc I posted on wiki
18:44:33 &lt; Gabriel403 &gt; EvanDotPro: I do however know not to use sha1, I stick with good old md5
18:44:40 &lt;weierophinney &gt; Gabriel403: LOL
18:44:44 &lt; Freeaqingme &gt; Spabby, url ;)
18:44:53 &lt; Spabby_ &gt; pop in and chat with myself and mwillbanks any time in .2
18:45:05 &lt;dmitrybelyako &gt; Spabby_ have a link?
18:45:10 &lt;weierophinney &gt; kk, folks, I'm calling it -- until next week!
</pre>
]]></ac:plain-text-body></ac:macro>