View Source

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


<li>Date: 27 June 2012, 20:00-21:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-06-27 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 July 2012</li>


<h3>Annotations: Doctrine Common / Own Implementation</h3>

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

<p>Marco Pivetta (ocramius) asked if we should use our own annotation implementation, or use the one from Doctrine\Common instead.</p>

<p>Matthew (weierophinney) indicated that he had made the following conclusions:</p>

<li>It does not make sense for ZF to have its own annotation syntax, particularly since we're already inconsistent about it (some take raw strings, others JSON-encoded text). Using a standard already used in multiple projects makes sense.</li>
<li>However, ZF should be flexible enough to allow annotations using alternate syntaxes. Doctrine\Common currently only allows ignoring such annotations.</li>

<p>His suggestion is to use the Doctrine\Common lexer/parser as a default, but allow developers to plug in to the annotation manager to handle alternate annotation styles on a per-annotation basis.</p>

<p>The main questions from those present at this point was how ZF will package. Composer and Pyrus are simple, and require trivial changes to packaging. For the tarball/zipball packages, we will include Doctrine\Common in the vendor directory, and include instructions for how to configure autoloading.</p>

<p><strong>tl;dr</strong>: ZF2's Zend\Code\Annotation component will have a dependency on Doctrine\Common for its annotation lexer/parser.</p>

<h3>Documentation RFC</h3>

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

<p>During the previous IRC meeting, we decided that Gary Hockin (Spabby), Rob Allen (Akrabat), and Matthew (weierophiney) would create an RFC with specific recommendations on how to improve the documentation. Matthew posted it shortly before the meeting, and summarized the main points:</p>

<li>Create a cohesive user guide/tutorial, separate from the reference documents</li>
<li>Have a common structure for reference documents</li>
<li>Use reST + Sphinx + instead of DocBook + PhD + Lucene</li>

<p>The benefits include: easier to write and translate documentation, easier to render (and automated rendering via, predictable structure within individual documents, and cohesive and consistent examples (we'd use a reference project for the user guide, and by extension for all examples).</p>

<p>Consensus was immediate and in favor of the recommendations. We will be working on a timeline for changes, but hope to have something in place for the stable release.</p>

<p><strong>tl;dr</strong>: Documentation will get a huge overhaul, and be easier to create!</p>


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

<p>Gary Hockin (Spabby) has pointed out that OAuth is largely unmaintained, and OAuth2 development is still in progress. He wanted to discuss where these should live, and the fate of Zend\OAuth.</p>

<p>As several people noted, Twitter still utilizes OAuth v1, which means we can't make it go away. Also noted was that a number of people have provided contributions to the component over the last few months, bringing it to a stable status &ndash; Zend\Service\Twitter is working correctly with it at this time.</p>

<p>After much discussion, we decided:</p>

<li>OAuth will move to a separate repository, under the name &quot;ZendService\OAuth&quot;</li>
<li>OAuth2 will also be in a separate repository, under the name &quot;ZendService\OAuth2&quot;</li>

<p>Both will be developed as <em>libraries</em> (not modules).</p>

<p><strong>tl;dr</strong>: We'll continue to ship OAuth, but under a different namespace. OAuth2 support is forthcoming.</p>


<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
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) */
word-wrap: break-word; /* IE 5.5+ */
border: 1px solid darkgray;
padding: 0.5em;
<pre class="log">
20:02:29 &lt;weierophinney&gt; Okay, agenda is posted:
20:02:49 &lt;weierophinney&gt; who owns the OAuth topic? That's first up.
20:03:00 &lt; Spabby1&gt; me
20:03:11 &lt; SpiffyJr&gt; I did some maintenance work to get OAuth working for ZF2 but I'm not sure of the current state nor do I want to maintain it.
20:03:18 &lt; Spabby1&gt; can wait if more important stuff?
20:03:43 &lt;weierophinney&gt; Spabby1: can what wait? discussion? or release of the oauth component?
20:03:56 &lt; Spabby1&gt; discussion, we can move it down agenda
20:04:07 &lt;weierophinney&gt; Spabby1: sure.
20:04:16 &lt;weierophinney&gt; Moving on to Annotations, then.
20:04:36 &lt;weierophinney&gt; As I noted in a comment on the agenda, I made the decision late Monday to use the Doctrine\Common annotation parser.
20:04:45 &lt; Spabby1&gt; (not because there s 30 mins left of football honest)
20:04:52 &lt; Akrabat&gt; evening all
20:04:55 &lt; DASPRiD&gt; weierophinney, oh?
20:04:56 &lt;weierophinney&gt; I also note in the comment the two different approaches to take.
20:05:04 &lt; SpiffyJr&gt; orly?
20:05:10 * ocramius reading comments
20:05:11 &lt; guilhermeblanco&gt; hi
20:05:25 &lt;weierophinney&gt; 1 is to use the AnnotationReader directly. I don't think this is good, as it doesn't fit with how our Scanner or Reflection components work.
20:05:54 &lt; DASPRiD&gt; clearly only option 2 makes sense
20:05:56 &lt;weierophinney&gt; 2 is to simply use the lexer/parser within a custom annoation reader. This gives us a default syntax to use, but also gives us flexibility as noted above, and ability to allow other annotation syntax formats.
20:06:01 &lt; PadraicB&gt; weierophinney, what was rationale for the choice?
20:06:33 &lt;weierophinney&gt; PadraicB: so, I had two concerns:
20:06:42 &lt; ocramius&gt; if reminder: agenda is at
20:06:54 &lt;weierophinney&gt; 1) We were simply making up a syntax out of thin air, and not even being consistent about it.
20:07:11 &lt;weierophinney&gt; It made sense to adopt something that's used in other projects, and offload the work.
20:07:29 &lt;weierophinney&gt; 2) We still want to allow arbitrary syntaxes, as we don't know what people are using in their own projects already.
20:07:49 &lt; SpiffyJr&gt; Won't we still have the issue of having to register Zend annotations in the Doctrine reader?
20:07:57 &lt;weierophinney&gt; PadraicB: (1) is answered by using doctrine\common. (2) is answered by simply using the parser/lexer as one option for parsing annotation content.
20:08:12 &lt;weierophinney&gt; SpiffyJr: yes, but we have a PR in for them about that already.
20:08:26 &lt; SpiffyJr&gt; Link or summary?
20:08:37 &lt; SpiffyJr&gt; Namespace ignore would work...
20:08:37 &lt; ocramius&gt; SpiffyJr: nothing solid yet :)
20:08:42 &lt;weierophinney&gt; SpiffyJr: and when it comes down to it, our annotations will now be compatible, so it's no longer an issue.
20:08:57 &lt;weierophinney&gt; SpiffyJr: ocramius can give you the link faster than me, I'm sure.
20:09:01 &lt; guilhermeblanco&gt; SpiffyJr:
20:09:02 &lt; ocramius&gt; SpiffyJr:
20:09:07 &lt; guilhermeblanco&gt; \o/
20:09:10 &lt; ocramius&gt; :D
20:09:15 &lt; Gabriel403&gt; ehe
20:09:24 &lt; PadraicB&gt; Hehe.
20:09:38 &lt; SpiffyJr&gt; The way doctrine annotations work is they're all loaded into memory even if not used, correct?
20:09:46 &lt; SpiffyJr&gt; (via register)
20:09:56 &lt; PadraicB&gt; weierophinney, cool
20:09:59 &lt;weierophinney&gt; SpiffyJr: yes
20:10:05 &lt; ocramius&gt; SpiffyJr: the definitions, yes
20:10:06 &lt; guilhermeblanco&gt; SpiffyJr: no... it loads the class entirely, but not all at once
20:10:22 &lt; SpiffyJr&gt; 2 &gt; 1? ;)
20:10:27 &lt; cgmartin&gt; my biggest concern was #2 so as long as that's taken into account, sounds good
20:10:35 &lt;weierophinney&gt; guilhermeblanco: what SpiffyJr is getting that is that as it parses a method or property for annotations, it loads each.
20:10:55 &lt;weierophinney&gt; cgmartin: yeah -- I've got a design, just need to write the code. Haven't had time the last two days
20:10:59 &lt; SpiffyJr&gt; weierophinney, I don't want a situation where we have double parsing/reading of classes for no reason.
20:11:00 &lt; guilhermeblanco&gt; weierophinney: sure... so it loads all definitions when processing a single class
20:11:29 &lt; SpiffyJr&gt; weierophinney, for example, Doctrine reader reading zend/doctrine annotations and our annotation builder reading zend annotations.
20:11:41 &lt;weierophinney&gt; SpiffyJr: ah -- yeah, that's entirely possible, actually.
20:11:48 &lt; SpiffyJr&gt; Which isn't ideal.
20:12:02 &lt;weierophinney&gt; as in, that situation could happen. Definitely not ideal, but I'm not 100% sure how to avoid it.
20:12:30 &lt; ocramius&gt; weierophinney: such a case could be avoided by making the ZF annotation "manager" implement Doctrine's interface
20:12:38 &lt; ocramius&gt; or a wrapper in doctrine to use ZF annotation manager
20:12:44 &lt; ocramius&gt; both ways work
20:12:57 &lt; ocramius&gt; so you share a single instance and have parsing only once
20:13:00 &lt; Maks3w&gt; I'm against to use doctrine annotations while shill in doctrine-common. Could Doctrine do a Fork of annotations a treat that feature as an independent project?
20:13:07 &lt; Maks3w&gt; *still
20:13:11 &lt; SpiffyJr&gt; I'd rather it be a separate project as well.
20:13:19 &lt; outeredge&gt; +1
20:13:20 &lt; SpiffyJr&gt; But, eh, I don't see that happening anytime soon.
20:13:33 &lt; Akrabat&gt; That's already planned I thought ?
20:13:35 &lt;weierophinney&gt; Maks3w: we can always change to the individual component once that happens, but it's not a good reason to not adopt right now.
20:13:38 &lt; ocramius&gt; Maks3w: splitting the repo (subtree + package) is something that seems to have ALREADY to happen
20:13:39 &lt; mattcockayne&gt; Nothing stopping us forking it on their behalf
20:13:41 &lt; ocramius&gt; we just need to do it
20:13:45 &lt; PadraicB&gt; Maks3w, while that would be ideal I doubt it's a deal breaker
20:13:45 &lt; Akrabat&gt; sure I heard someone say that they were splitting it up
20:13:57 &lt; ocramius&gt; since more and more libs are asking only for pieces of doctrine common
20:14:01 &lt; ocramius&gt; guilhermeblanco, asm89, confirm?
20:14:05 &lt; SpiffyJr&gt; If the package is eventually split up my only concern is double loading annotations.
20:14:08 &lt;weierophinney&gt; yes -- there are plans to split it up, but we shouldn't wait to adopt based on that.
20:14:17 &lt; Akrabat&gt; agreed
20:14:20 &lt; PadraicB&gt; weierophinney, agreed
20:14:23 &lt; asm89&gt; ocramius: that's correct
20:14:24 &lt; guilhermeblanco&gt; ocramius: we're splitting the repositories, yes
20:14:27 &lt;weierophinney&gt; SpiffyJr: if you use composer or pyrus, shouldn't be an issue.
20:14:48 &lt; Akrabat&gt; I'm very +1 on using Doctrine's annotation parser if it meets our requirements
20:15:14 &lt; ocramius&gt; weierophinney: about double parsing... I guess we need to wait for your ideas to see if we can either make the manager compatible with Doctrine\Common\Annotations\Reader interface
20:15:18 &lt; ocramius&gt; or a wrapper in Doctrine
20:15:31 &lt; guilhermeblanco&gt; ocramius: maybe we can use the same cache keys
20:15:34 &lt;weierophinney&gt; Akrabat: I think it makes sense, definitely. More sense than arbitrarily accepting raw strings vs JSON-encoded strings, etc.
20:15:37 &lt; guilhermeblanco&gt; so we don't double the parsing
20:15:37 &lt; guilhermeblanco&gt; =)
20:15:44 &lt; DASPRiD&gt; weierophinney, i hope that that won't conflict with autoloading / users adding a newer/older version to their loader path
20:15:49 &lt; ocramius&gt; guilhermeblanco: seems weak... I don't trust caches :)
20:15:50 &lt; Maks3w&gt; If doctrine annotations have his own package I'm feel better because I feel that the project has more autonomy and less dependency with the Doctrine ORM roadmap
20:16:11 &lt; ocramius&gt; guilhermeblanco: since ZF2 is going to use common, it could be possible to have an adapter in it
20:16:16 &lt; guilhermeblanco&gt; Maks3w: it's already very far from ORM dictating what Annotation does
20:16:21 &lt; ocramius&gt; new ZfAnnReader($annManager)
20:16:27 &lt;weierophinney&gt; ocramius: I can try to implement the interface. I'm not sure if it suits the needs we have, per my comments (being able to pull annotations granularly per object entity -- property, method, class, etc.)
20:16:36 &lt; SpiffyJr&gt; guilhermeblanco, yea, but when people see Doctrine\* they assume ORM
20:16:51 &lt; ocramius&gt; weierophinney: I also don't think it would be a problem. It could be eventually handled by DoctrineModule
20:16:54 &lt; SpiffyJr&gt; guilhermeblanco, Doctrine\Annotation will segregate it further.
20:16:57 &lt; ocramius&gt; if it is too specific
20:17:03 &lt; guilhermeblanco&gt; SpiffyJr: a terrible mistake. We have over 45 repositories.... we are not strict to ORM. =)
20:17:12 &lt; SpiffyJr&gt; guilhermeblanco, indeed.
20:17:15 &lt; Akrabat&gt; guilhermeblanco: I have to admit to the same predudice
20:17:15 &lt;weierophinney&gt; Maks3w: Doctrine\Common is not ORM code -- it's general-purpose.
20:17:28 &lt; Maks3w&gt; Also I'm against to must have doctrine-common installed for use Zend\Form or any other component. Annotations must be a plugin that not block any other functionality
20:17:35 &lt; Akrabat&gt; Doctrine has marketed the name as synonymous with "ORM"
20:17:35 &lt; DASPRiD&gt; not to confuse with Zf Commons ;)
20:17:38 &lt; guilhermeblanco&gt; Maks3w: Doctrine\Common is mainly a repository that should be built-in in PHP
20:17:40 &lt; SpiffyJr&gt; weierophinney, guilhermeblanco but what's the first thing that people think of when they don't know better?
20:17:43 &lt; PadraicB&gt; If we restricted libs to independent units - there would be very few libs to depends on ;)
20:17:59 &lt; SpiffyJr&gt; Anyway, moot point. Splitting annotations up makes me happy.
20:18:02 &lt;weierophinney&gt; Maks3w: annotation support in Zend\Form is optional anyways.
20:18:04 &lt; Akrabat&gt; however, it's moot :)
20:18:07 &lt; guilhermeblanco&gt; weierophinney: back to the subject
20:18:32 &lt; guilhermeblanco&gt; Are you focusing on option 1 or 2?
20:18:34 &lt; SpiffyJr&gt; 2
20:18:36 &lt;weierophinney&gt; guilhermeblanco: 2 for now
20:18:43 &lt; guilhermeblanco&gt; do you need me to remove the final from AnnotationReader?
20:18:44 &lt;weierophinney&gt; but I'll investigate 1 a little.
20:18:48 &lt; SpiffyJr&gt; AnnotationReader is final? Heh.
20:18:51 &lt; Maks3w&gt; weierophinney: perfect
20:18:53 &lt;weierophinney&gt; guilhermeblanco: for 1 to work, yes, would need final removed.
20:19:12 &lt; guilhermeblanco&gt; weierophinney: ok... I will remove so you can experiment with some freedom
20:19:21 &lt; DASPRiD&gt; guilhermeblanco, when it is common code, there really shouldn't be anything final ;)
20:19:31 &lt; SpiffyJr&gt; weierophinney, how are we planning on shipping this?
20:19:42 &lt; SpiffyJr&gt; how are people going to know they need doctrine/common
20:19:43 &lt; guilhermeblanco&gt; just remember we have different mindsets, we enable things upon valid use cases
20:19:46 &lt; ocramius&gt; DASPRiD: isn't intended for extending. people can still implement interface and wrap instances ;)
20:19:52 &lt; DASPRiD&gt; SpiffyJr, i'd say shipping separately
20:19:52 &lt; guilhermeblanco&gt; DASPRiD: because we adopt Poka-yoke principle there
20:19:59 &lt;weierophinney&gt; SpiffyJr: well, composer and pyrus are simple. I'm still looking at how to put it in the tarballs.
20:20:02 &lt; DASPRiD&gt; guilhermeblanco, uh?
20:20:21 &lt; SpiffyJr&gt; weierophinney, I was looking more for the non-composer route.
20:20:28 &lt; guilhermeblanco&gt; DASPRiD: Poka-yoke is a Lean principle that we close all the doors, leaving only one open, the right one
20:20:31 &lt; SpiffyJr&gt; weierophinney, personally, I'd like to see ZF tool be a wrapper for composer...
20:20:37 &lt; SpiffyJr&gt; weierophinney, could handle situations like this easily
20:20:48 &lt; SpiffyJr&gt; weierophinney, creating the composer.json with correct requires, etc.
20:20:49 &lt;weierophinney&gt; SpiffyJr: tell Thinkscape. If you can find him.
20:20:50 &lt; DASPRiD&gt; guilhermeblanco, there's not always a single right one ;)#
20:20:59 &lt; Gabriel403&gt; zf2, the dependency framework
20:21:10 &lt; DASPRiD&gt; lol
20:21:15 &lt; ocramius&gt; Gabriel403: that one is symfony ;)
20:21:19 &lt; guilhermeblanco&gt; DASPRiD: so you have to give a valid second, then we enable....
20:21:20 &lt; SpiffyJr&gt; Gabriel403, no more so than Symfony (technically, less than Symfony)
20:21:23 &lt;weierophinney&gt; SpiffyJr: but most likely we'd include Doctrine\Common within the ZF2 tarball/zipball distributions.
20:21:35 &lt; SpiffyJr&gt; weierophinney, in vendor/ I presume?
20:21:39 &lt; ocramius&gt; indeed :) the only problem remains autoloading
20:21:48 &lt;weierophinney&gt; SpiffyJr: yes
20:21:51 &lt; ocramius&gt; s/remains/that remains is
20:21:53 &lt; DASPRiD&gt; weierophinney, back to my question, what if people have newer/older versions of doctrine/common in their loader paths?
20:21:55 &lt;weierophinney&gt; ocramius: yep.
20:22:05 &lt; Gabriel403&gt; SpiffyJr: i don't use symfony
20:22:13 &lt; PadraicB&gt; DASPRiD, manually resolve to a common version?
20:22:22 &lt; DASPRiD&gt; PadraicB, mh?
20:22:33 &lt; guilhermeblanco&gt; weierophinney: all yours...
20:22:35 &lt; PadraicB&gt; DASPRiD, this is a problem for which package managers were invented (and should be used)
20:22:39 &lt;weierophinney&gt; DASPRiD: ask guilhermeblanco and ocramius for that one. :) I expect we'd resolve to whichever one is highest version, as they tend to be very strict about BC.
20:22:41 &lt; SpiffyJr&gt; Gabriel403, my point is, dependencies aren't necessarily bad if they a) reduce maintenance overhead and b) offer the same features
20:22:46 &lt;weierophinney&gt; guilhermeblanco: thanks!
20:23:03 &lt;weierophinney&gt; kk, can we move on to next item now?
20:23:04 &lt; DASPRiD&gt; PadraicB, so in that case: zendframework/zendframework replaces doctrine/common, right?
20:23:06 &lt; Maks3w&gt; SpiffyJr: +1
20:23:09 &lt; Akrabat&gt; weierophinney: yes
20:23:20 &lt; guilhermeblanco&gt; weierophinney: me is leaving
20:23:23 &lt; guilhermeblanco&gt; but thanks
20:23:26 &lt; PadraicB&gt; DASPRiD, if it sets a higher version as a dep - likely.
20:23:31 &lt;weierophinney&gt; Documentation RFC is the next topic
20:23:32 &lt; ocramius&gt; DASPRiD: wouldn't do that with composer, but yes, that can be done
20:23:33 &lt;weierophinney&gt;
20:23:47 * SpiffyJr tries to skim really fast
20:23:57 &lt;weierophinney&gt; so, if you haven't read, the main ideas are:
20:24:14 &lt; PadraicB&gt; Kill Doctrine. Bury Doctrine. Make sure it stays dead?
20:24:17 &lt; DASPRiD&gt; sphynx &lt;3
20:24:18 &lt;weierophinney&gt; * Create a cohesive tutorial, separate from teh reference documents
20:24:31 &lt;weierophinney&gt; * Have a common structure for reference documents
20:24:48 &lt;weierophinney&gt; * Use instead of DocBook+PhD
20:25:06 &lt; cgmartin&gt; "reStructuredText is a simple markup language similar to Markdown. Unlike markdown, however, it supports defining labels and cross-referencing" like the sound of that
20:25:08 &lt; outeredge&gt; PadraicB: unnecessary
20:25:25 &lt; PadraicB&gt; outeredge, I know ;)
20:25:36 &lt; outeredge&gt; ;)
20:25:37 &lt; SpiffyJr&gt; +1 for markdown similar language
20:25:42 &lt;weierophinney&gt; That's the nutshell version; read the RFC if you want the full bit
20:25:53 &lt; DASPRiD&gt; i'm already +1ing the rfc
20:25:57 &lt;weierophinney&gt; Structure is pulled from my original proposal, and has been generally agreed upon.
20:26:04 &lt; Akrabat&gt; rST is quite nice - has a formal way to extend the syntax
20:26:15 &lt; SpiffyJr&gt; Does GitHub read rST?
20:26:18 &lt;weierophinney&gt; Akrabat: indeed -- been reading more on it, and really like it.
20:26:20 &lt;weierophinney&gt; SpiffyJr: not sure.
20:26:24 &lt; Maks3w&gt; +1 rest+sphink. -1 readthedocs if github pages have support
20:26:25 &lt; mattcockayne&gt; +1 reST & sphinx
20:26:29 &lt;weierophinney&gt; SpiffyJr: check the doctrine docs and see -- they use it
20:26:34 &lt; Gabriel403&gt; Do any IDEs help with autogenerating it?
20:26:39 &lt; Akrabat&gt; SpiffyJr: yes for readme files if you do readme.rst
20:26:40 &lt; ocramius&gt; SpiffyJr: yes, it can read it, but it isn't really supported
20:26:40 &lt; Spabby1&gt; +1 all points
20:26:47 &lt;weierophinney&gt; Maks3w: readthedocs gives us something else, though: search
20:26:50 &lt; DASPRiD&gt; Gabriel403, sure, lets simply make an ant task ;)
20:26:58 &lt; SpiffyJr&gt; weierophinney, vote time!
20:27:00 &lt; ocramius&gt; the main problem is code blocks, not sure it is already working
20:27:03 &lt; Gabriel403&gt; DASPRiD: i don't know how to do that
20:27:17 &lt; SpiffyJr&gt; I'd upvote anything that isn't docbook ;)
20:27:17 &lt; Gabriel403&gt; DASPRiD: i type /**&lt;enter&gt; and fill in the bits
20:27:26 &lt; Maks3w&gt; weierophinney: the nTh site more where find ZF2 things? absolutely no!!!
20:27:29 &lt;weierophinney&gt; ocramius: it uses pygments for code blocks... all examples I've seen look good.
20:27:30 &lt; DASPRiD&gt; Gabriel403, uh?
20:27:36 &lt; DASPRiD&gt; Gabriel403, completely different topic! :)
20:27:45 &lt; mattcockayne&gt; weierophinney: search is out of the box with sphinx... no need for readthedocs
20:27:46 &lt; jurians&gt; weierophinney: links from examples are all broken :)
20:27:47 &lt; Zend\Bot&gt; jurians, Solow wants me to remind you about your article called "using 3rd party modules in zf2" and asked me to ask you to ping him when you're in. He has some questions concerning this specific article.
20:27:47 &lt; Zend\Bot&gt; jurians, Solow wants me to remind you about the last reminder. Just ignore it, he decided to post a comment instead.
20:27:47 &lt; Akrabat&gt; Maks3w: nTh?
20:27:47 &lt; DASPRiD&gt; Gabriel403, this is about manual, not inline documentation
20:27:55 &lt; jurians&gt; lol
20:28:03 &lt;weierophinney&gt; Maks3w: you're missing the point -- the docs they generate we incorporate into our site.
20:28:06 &lt; DASPRiD&gt; jurians, lol
20:28:12 &lt;weierophinney&gt; Maks3w: look at how doctrine has done it.
20:28:15 &lt; ocramius&gt; weierophinney: fabolous...
20:28:17 &lt; ocramius&gt; :)
20:28:23 &lt; PadraicB&gt; No nth site to remember ;)
20:28:29 &lt;weierophinney&gt; jurians: I know -- irrelevant anyways, as those are docbook
20:28:38 &lt; DASPRiD&gt; (code and unit tests are still the best manual ;))
20:28:41 &lt; Gabriel403&gt; DASPRiD: ah, I didn't realise people used docblook for actual manuals rather than apis
20:28:43 &lt; jurians&gt; weierophinney: yeah, just to let you know, np :)
20:28:47 &lt; Maks3w&gt; +1 for have a common structure
20:28:56 &lt; Akrabat&gt; Gabriel403: docbook != docblocks
20:28:57 &lt;weierophinney&gt; mattcockayne: um, I think you're confusing sphinx search with sphinx the documentation system.
20:29:07 &lt; SpiffyJr&gt; weierophinney, i see that readthedocs has git support... does that mean we're splitting docs out of the primary repo?
20:29:07 &lt; DASPRiD&gt; he is
20:29:12 &lt; Maks3w&gt; +0 for tutorial. I see hard to maintain
20:29:13 &lt; Gabriel403&gt; Akrabat: i mistyped docblock
20:29:22 &lt; Akrabat&gt; kk
20:29:30 &lt; SpiffyJr&gt;
20:29:31 &lt;weierophinney&gt; SpiffyJr: yes
20:29:32 &lt; DASPRiD&gt; isn't the skeleton application already a great tutorial/quick start?
20:29:34 &lt; PadraicB&gt; Maks3w - needs something to get people over the initial learning curve
20:29:40 &lt; Akrabat&gt; DASPRiD: no
20:29:48 &lt; SpiffyJr&gt; It has limited support it seems.
20:29:50 &lt; mattcockayne&gt; weierophinney: nope... i use sphinx for my documentation and it generates a search index also
20:29:51 &lt;weierophinney&gt; DASPRiD: needs a narrative. It's not nearly sufficient.
20:29:59 &lt;weierophinney&gt; mattcockayne: oh, cool!
20:30:02 &lt; outeredge&gt; +1 for cohesive separate tutorial
20:30:02 &lt; Maks3w&gt; small tutorial, some start, concepts and how to find in the manual
20:30:05 &lt;weierophinney&gt; mattcockayne: awesome to know!
20:30:12 &lt; ocramius&gt; DASPRiD: nope
20:30:14 &lt; Maks3w&gt; the examples in the manual
20:30:15 &lt; DASPRiD&gt; weierophinney, okay, sure, but a tutorial can be based on it
20:30:25 &lt; Akrabat&gt; skeleton is terrible as an tutorial as it is code not explantatory prose
20:30:32 &lt;weierophinney&gt; DASPRiD: yes -- but it's not enough. We need to demonstrate building a full app, not just "hello world"
20:30:33 &lt; outeredge&gt; like jobeet was for symfony
20:30:39 &lt; Akrabat&gt; also skeleton doesn't actually do enough
20:30:46 &lt; Akrabat&gt; outeredge: askeet - yes
20:30:50 &lt; PadraicB&gt; Maks3w, manual examples are pretty bad actually - no context on actual use in an app
20:31:00 &lt; Spabby1&gt; DASPRiD: tutorial will include installing skeleton app and building a nice CRUD application, proposal is more comprehensive version of Akrabat's tutorial
20:31:05 &lt; outeredge&gt; Akrabat: it's been that long lol
20:31:07 &lt; PadraicB&gt; They can be surprisingly frustrating
20:31:09 &lt; DASPRiD&gt; Spabby1, ah
20:31:10 &lt;weierophinney&gt; PadraicB: agreed -- in the RFC, we mention that examples should all be relevant to the sample app.
20:31:20 &lt; SpiffyJr&gt; weierophinney, +1
20:31:33 &lt; Spabby1&gt; then all sample code in reference manual will be in the context of this tutorial sample app
20:31:38 &lt; PadraicB&gt; Yep, and I agree with that approach ( insofar as it's possible to link them)
20:31:43 &lt; Akrabat&gt; of course, everyone in here is self-selecting as not needing tutorial level docs :)
20:31:54 &lt; PadraicB&gt; true
20:31:56 &lt; outeredge&gt;
20:31:57 &lt; Maks3w&gt; too examples, some times only you need to show a practical case for use some parameters
20:32:28 &lt; PadraicB&gt; Maks3w, the number of times I read the source and avoided the manual disagrees with your assertion ;)
20:32:42 &lt; Akrabat&gt; examples within the reference manual will probably be different from the exact tutorial-project, but in the same "concept-space" if we can
20:32:50 &lt; DASPRiD&gt; PadraicB, source or unit tests :)
20:32:51 &lt; Gabriel403&gt; i fricking need a tutorial to tell the difference between doclock and docbook it seems
20:32:55 &lt; jurians&gt; Akrabat: it would be nice to have independent chapters of end-user docs
20:32:58 &lt; Maks3w&gt; PadraicB: well that is part of use a ZF1 manual with a ZF2 component without any common structure
20:33:04 &lt;weierophinney&gt; askeet and jobeet were really, really cool in terms of getting people up to speed on symfony . We need something of that quality or better, I feel.
20:33:04 &lt; DASPRiD&gt; Gabriel403, doc lock? o0
20:33:11 &lt;weierophinney&gt; Akrabat: +
20:33:17 &lt; jurians&gt; Akrabat: so they can be read when needed, not completely from start till end
20:33:18 &lt; Gabriel403&gt; DASPRiD: again, mistype of docblock
20:33:19 &lt; PadraicB&gt; DASPRiD, it was ZF1 - source (the tests were rarely readable)
20:33:22 &lt; Akrabat&gt; jurians: yes, but in the reference, you may want other situation - e.g. cache adapters
20:33:31 &lt; DASPRiD&gt; PadraicB, surely weren't my tests! :D
20:33:48 &lt; PadraicB&gt; DASPRiD, I believe they were ALL your tests :P
20:34:11 &lt; jurians&gt; lol
20:34:12 &lt; Akrabat&gt; so the manual could show how to use each cache adapter within the same logical problem as the cache used in the tutorial-project, but by definition, all the cache adapters can't be in the tutorial-project
20:34:30 &lt; EvanDotPro&gt; re
20:34:36 &lt; DASPRiD&gt; EvanDotPro, too late! :P
20:34:40 &lt; jurians&gt; Akrabat: of course, I meant the end-user docs "narrative style" (which you call now tutorial?)
20:34:54 &lt; PadraicB&gt; weierophinney, I'll pop a few suggestions on the ML tomorrow - I vaguely remember an RFC where I may have promised to write a security guide for ZF2. My memory is desperate to forget that.
20:35:10 &lt;weierophinney&gt; PadraicB: YOU DID. I WILL VERIFY NOW. :)
20:35:21 &lt; cgmartin&gt; lol
20:35:45 &lt;weierophinney&gt; kk, so anybody with any concerns about the RFC at this time?
20:35:46 &lt; Akrabat&gt; jurians: I quite like the phrase user-guide for the narrative docs and reference-manual for the detailed per-component docs
20:35:57 &lt; Spabby1&gt; +1
20:36:03 &lt; jurians&gt; nice one, +1 :)
20:36:05 &lt;weierophinney&gt; Akrabat, jurians +1
20:36:25 &lt; Akrabat&gt; weierophinney: I'm not sure I want to tie the "getting started" intro tutorial to the tutorial project that builds up over mulitple chapters
20:36:27 &lt; PadraicB&gt; No concerns here - +1
20:36:27 &lt; ocramius&gt; fine by me :)
20:36:33 &lt; ocramius&gt; +1
20:36:36 &lt; Akrabat&gt; need to think about that bit
20:36:36 &lt; mattcockayne&gt; +1
20:36:38 &lt; outeredge&gt; +1
20:36:39 &lt; Akrabat&gt; +1
20:36:45 &lt; SpiffyJr&gt; what they all said
20:36:46 &lt;weierophinney&gt; Akrabat: kk -- we may want that separate. We can hash that out elsewhere.
20:36:51 &lt; Akrabat&gt; exactly
20:36:59 &lt; cgmartin&gt; no concerns, what were next steps again on this?
20:37:09 &lt; Maks3w&gt; I think that usually with a small tutorial and a complete API Doc you can do decent things
20:37:28 &lt;weierophinney&gt; Maks3w: clearly you haven't supported ZF1 at all. :)
20:37:30 &lt; Maks3w&gt; but the API Doc must be completed and not only @param without descriptions
20:37:30 &lt; PadraicB&gt; Akrabat, it would be simpler to have them separate. Otherwise a risk of overcomplicating the simpler one for the sake for the longer tut?
20:37:41 &lt; Gabriel403&gt; Sorry, did i miss the vote on annotations?
20:37:42 &lt; Akrabat&gt; exactly
20:37:57 &lt;weierophinney&gt; cgmartin: we need to experiment with the tools for converting DB -&gt; reST, but once we know how that works, we'll likely post a call-to-action
20:37:59 &lt; SpiffyJr&gt; Gabriel403, we didn't really have one.
20:38:00 &lt; Akrabat&gt; and the absolute beginner needs simple crud to get going
20:38:14 &lt;weierophinney&gt; Gabriel403: there was no vote. Mainly me explaining what I did in the comment on the agenda. :)
20:38:16 &lt; cgmartin&gt; weierophinney: thanks
20:38:23 &lt; SpiffyJr&gt; Gabriel403, weierophinney invoked executive order ;)
20:38:24 &lt; Gabriel403&gt; Ah I see
20:38:34 &lt; Gabriel403&gt; :D
20:38:36 &lt; PadraicB&gt; Benevolent Dictator indeed ;)
20:38:43 &lt; outeredge&gt; Dictator Style
20:38:43 &lt; Spabby1&gt; don't worry, you'll know soon enough when volunteers are required
20:38:47 &lt; DASPRiD&gt; Supreme Allied Commander!
20:38:47 &lt; Maks3w&gt; For the small tutorial we could copy&paste the Akrabat's tutorial
20:38:55 &lt;weierophinney&gt; DASPRiD: don't make me hurt you. :)
20:38:59 &lt; DASPRiD&gt; weierophinney, :)
20:38:59 &lt; outeredge&gt; LOL
20:39:06 &lt;weierophinney&gt; Maks3w: that's what we'll be starting with, actually, and then expanding.
20:39:08 &lt; PadraicB&gt; SAC? Which kind? :P
20:39:19 &lt; Akrabat&gt; I see that DASPRiD owes weierophinney yet another beer...
20:39:24 &lt;weierophinney&gt; kk, moving on to OAuth...
20:39:25 &lt; Gabriel403&gt; Benevolent when you're doing what he says ;)
20:39:29 &lt;weierophinney&gt; Spabby1: you want to take this?
20:39:33 &lt; DASPRiD&gt; Akrabat, he'll get pretty drunk :P
20:39:37 &lt; Spabby1&gt; yep
20:40:12 &lt; Spabby1&gt; there was an awful RFC cobbled together by me here:
20:40:14 &lt; Gabriel403&gt; It was a crap game Spiffy1 :P
20:40:21 &lt; PadraicB&gt; brb (phone)
20:40:26 &lt; SpiffyJr&gt; lol Spiffy1
20:40:31 &lt; SpiffyJr&gt; Either's either Spabby1 or SpiffyJr
20:40:31 &lt; Spabby1&gt; basically, we have no maintainer for oauth 1 client
20:40:34 &lt; SpiffyJr&gt; Make up your mind!
20:41:00 &lt; Spabby1&gt; I have working oauth 2 client, and mwillbanks will be coding an oauth2 server implimentation
20:41:08 &lt; Spabby1&gt; so the question is where should all this live
20:41:28 &lt;weierophinney&gt; Do we need an oauth1 client still?
20:41:32 &lt; Spabby1&gt; I'm leaning towards making the entire OAuth area a ZendService module
20:41:37 &lt; SpiffyJr&gt; weierophinney, I think OAuth 2 is BC?
20:41:39 &lt; SpiffyJr&gt; Spabby1, ?
20:41:39 &lt; Spabby1&gt; weierophinney: I suspect so if only just for twitter
20:41:44 &lt;weierophinney&gt; Spabby1: separate repo, like the service compoents.
20:41:50 &lt; mattcockayne&gt; personally... would see it as a separate "service" component
20:41:51 &lt; Spabby1&gt; weierophinney: exactly
20:41:51 &lt;weierophinney&gt; Spabby1: fair enough.
20:41:59 &lt; cgmartin&gt; weierophinney +1
20:42:11 &lt; Spabby1&gt; hey cgmartin it was my proposal
20:42:15 &lt; Spabby1&gt; cheeky
20:42:17 &lt; Gabriel403&gt; weierophinney: how do you mean?
20:42:23 &lt;weierophinney&gt; You could create the repo yourself, and we could fork it in the organization when ready to adopt it.
20:42:25 &lt; cgmartin&gt; Spabby1 +2
20:42:32 &lt; Spabby1&gt; ZendService\OAuth
20:42:58 &lt;weierophinney&gt; Gabriel403: each service component will have its own repo, so that they can be versioned separately from the framework -- necessary, because APIs often change on a different schedule than our minor releases.
20:43:01 &lt; Spabby1&gt; hows the vote looking on components re: Zend\OAuth
20:43:06 &lt; mattcockayne&gt; +1 ZendService\OAuth
20:43:16 &lt; jurians&gt; +1
20:43:30 &lt; SpiffyJr&gt; +1 w/ separate repo
20:43:37 &lt; DASPRiD&gt; SpiffyJr, +1
20:43:48 &lt; EvanDotPro&gt; are we talking about putting the OAuth 2 stuff in a separate repo and moving the OAuth1 stuff there too?
20:43:49 &lt; ocramius&gt; fine by me :)
20:43:50 &lt; Spabby1&gt; I'm thinking ZendService\OAuth\OAuth\Client and ZendService\OAuth\OAuth2\Client
20:43:56 &lt; Spabby1&gt; EvanDotPro: yes
20:43:57 &lt; EvanDotPro&gt; ^^ yes, yeah.
20:43:59 &lt; EvanDotPro&gt; that*
20:44:03 &lt; Gabriel403&gt; weierophinney: I see, what will bring this all together? composer? or just manually releasing a unified? OR will they remain completely seperated out requiring the user to import them?&gt;
20:44:11 &lt; Maks3w&gt; For me Oauth2 is not a service
20:44:26 &lt; PadraicB&gt; back
20:44:27 &lt; Spabby1&gt; Maks3w: I would argue it is
20:44:37 &lt; Gabriel403&gt; Sorry my typing is shot to shit, sitting in the dark playing assassins creed :P
20:44:41 &lt; outeredge&gt; isn't Oauth2 a communication protocol _for_ a service?
20:44:42 &lt; EvanDotPro&gt; i'd rather have both OAuth implementations in one spot.. having OAuth 1 in the main repo and OAuth 2 separate makes no sense.
20:45:05 &lt; Maks3w&gt; outeredge: you will move RestClient to ZendService too?
20:45:06 &lt;weierophinney&gt; Gabriel403: we have all packaging in ZF2Package right now -- we just add more rules/scripts there.
20:45:06 &lt; Akrabat&gt; Why does Zend\Outh2 need to have a different release schedule to the main repo?
20:45:09 &lt; EvanDotPro&gt; Maks3w: it's like a service without vendor specific stuff.
20:45:12 &lt; jurians&gt; outeredge: +1 same thoughts. OAuth is protocol (in core) and services require it, imho
20:45:13 &lt; Maks3w&gt; or RPC clients?
20:45:15 &lt; Gabriel403&gt; weierophinney: k
20:45:23 &lt; outeredge&gt; Maks3w, I'd keep it in core
20:45:35 &lt; PadraicB&gt; P.S. OAuth should be unified somewhere - as a library (with a module making use it for app workflows if required)
20:45:38 &lt;weierophinney&gt; Akrabat: well, keeping it in would suggest we should also keep in OpenID, InfoCard, etc. They're at heart web services.
20:45:45 &lt; EvanDotPro&gt; i don't care where it goes, but they should both be in one spot (1 and 2)
20:45:55 &lt;weierophinney&gt; Akrabat: it likely doesn't need a separate release schedule.
20:46:04 &lt; Akrabat&gt; weierophinney: good point.
20:46:04 &lt; PadraicB&gt; EvanDotPro, agreed - otherwise it'll be confusion finding them
20:46:05 &lt; Akrabat&gt; hmm
20:46:08 &lt; Gabriel403&gt; EvanDotPro: +1
20:46:18 &lt; DASPRiD&gt; EvanDotPro, +1
20:46:18 &lt; Spabby1&gt; the current implementation of OAUth2 includes vendor option files for one line usage
20:46:32 &lt;weierophinney&gt; So, I'm seeing votes to keep them together, but some disagreement on where they should live.
20:46:42 &lt; jurians&gt; EvanDotPro: but don't call is Foo\Oauth\Oauth2\* and Foo\Oauth\Oauth1\* but skip the Oauth part
20:46:52 &lt; jurians&gt; is/it
20:46:53 &lt; Akrabat&gt; I don't like ZendService\OAuth\OAuth1 and ZendService\OAuth\OAuth2 though. Would rather ZendService\OAuth1 and ZendService\OAuth2
20:47:02 &lt; jurians&gt; ^^ same thoughts :)
20:47:04 &lt; EvanDotPro&gt; jurians: Akrabat: +1
20:47:05 &lt; SocalNick&gt; For the questions about OAuth2 as service, when you are interacting with a Service that requires OAuth2, you first request an Access Token from an Auth Server:
20:47:16 &lt; SpiffyJr&gt; ZendService\Oauth ZendService\Oauth1
20:47:18 &lt; Akrabat&gt; Spabby1: good argument for ZendService
20:47:24 &lt; PadraicB&gt; My point about libs is, I don't want Modules to go through to use them - I don't exclusively use ZF
20:47:34 &lt; Spabby1&gt; SocalNick: yes indeed
20:47:37 &lt; SpiffyJr&gt; Similar to how they do outdated/uncommon packages in debian
20:47:42 &lt; jurians&gt; kk, Oauth to module is fine for me too, good arguments :)
20:47:43 &lt; Spabby1&gt; it's is only an authentication service
20:48:07 &lt; Spabby1&gt; also remember that there will be a server component to the OAuth2 module
20:48:20 &lt; Akrabat&gt; I'm +1 on ZendService component for OAuth 2 so that the "one-liner" connects can be updated out of sync with ZF2
20:48:45 &lt; Akrabat&gt; i.e. I like that ability with the OAuth2 implementation
20:48:53 &lt; Spabby1&gt; Akrabat: ta :)
20:49:22 &lt; Spabby1&gt; are we saying have oauth and oauth2 as service modules, removing oauth from core?
20:49:23 &lt; Akrabat&gt; which as EvanDotPro notes, means that I'm in favour of moving OAuth1 to ZendService for consistency
20:49:34 &lt;weierophinney&gt; going to sum up:
20:49:36 &lt; Gabriel403&gt; oauth1 oauth2 as service modules imo
20:49:43 &lt; Akrabat&gt; esp if we do OpenId too
20:49:44 &lt; ocramius&gt; I'm a bit conflicted on the release cycle...
20:49:53 &lt;weierophinney&gt; * OAuth and OAuth2 as separate REPOS (not modules, folks -- they're libraries)
20:50:04 &lt; DASPRiD&gt; i wonder, why not one oauth component support both oauth and oath2?
20:50:04 &lt; Spabby1&gt; it makes it easier for me as I don't need to take on maintanence of oauth1 as well :P
20:50:05 &lt; jurians&gt; ocramius: but it is just required for vendor specific options, noting more afaik
20:50:16 &lt; Spabby1&gt; jurians: correct
20:50:30 &lt;weierophinney&gt; DASPRiD: see above discussion. It sounds like they'd have different development timelines
20:50:34 &lt; Spabby1&gt; it COULD go in core as the options shouldn't update very often at all
20:50:42 &lt; PadraicB&gt; DASPRiD, believe me - v1 was frickin' bad enough to get into one library. Mixing two in one lib is nuts ;)
20:50:43 &lt; DASPRiD&gt; weierophinney, i c
20:51:39 &lt; Spabby1&gt; weierophinney: do you have access to the current status of the components vote?
20:51:42 &lt; PadraicB&gt; Spabby1, to recap - what is current status of OAuth1?
20:51:45 &lt; Akrabat&gt; Oauth1 is very different from 2 as i understand it
20:51:50 &lt;weierophinney&gt; Spabby1: yep -- what do you want to know?
20:52:04 &lt; Spabby1&gt; how many votes for Zend\OAuth
20:52:11 &lt;weierophinney&gt; PadraicB: OAuth1 is tested and basically works, but nobody wants to maintain.
20:52:21 &lt; Spabby1&gt; PadraicB: working but unmaintained
20:52:25 &lt; DASPRiD&gt; is oauth1 used anywhere on the web?
20:52:32 &lt; SpiffyJr&gt; I updated it for ZF2 but I'm not wanting to maintain it.
20:52:35 &lt; Spabby1&gt; DASPRiD: Twitter if am correct
20:52:37 &lt; SpiffyJr&gt; So it works fine.
20:52:41 &lt;weierophinney&gt; SpiffyJr: 81% in favor of keeping.
20:52:45 &lt; DASPRiD&gt; SpiffyJr, they need upgrade! ;)
20:52:47 &lt; Spabby1&gt; ha
20:52:50 &lt; PadraicB&gt; Ahh, did I resign maintainance (my AWOL periods notwithstanding?)
20:52:52 &lt; SpiffyJr&gt; o_O
20:52:55 &lt;weierophinney&gt; or, rather, Spabby1 81% in favor of keeping
20:52:56 &lt; Spabby1&gt; even weierophinney confuses us SpiffyJr
20:52:57 &lt; SpiffyJr&gt; weierophinney, you'll notice I downvoted it!
20:53:01 &lt;weierophinney&gt; DASPRiD: twitter.
20:53:09 &lt; SpiffyJr&gt; Spabby1, everyone does... I demand you change your name.
20:53:14 &lt;weierophinney&gt; PadraicB: TAG, YOU'RE IT AGAIN!
20:53:32 &lt; PadraicB&gt; weierophinney, I always figured I was... 0_0 ;)
20:53:38 &lt; DASPRiD&gt; ;)
20:53:42 &lt;weierophinney&gt; Spabby1: it's the auto completion. I'm used to having the first two letters autocomplete. You guys conflict.
20:53:52 &lt; Spabby1&gt; have we voted for moving Zend\OAuth to ZendService\OAuth and creating Zend\OAuth2
20:53:58 &lt; Spabby1&gt; or can we vote
20:54:05 &lt; Spabby1&gt; or something
20:54:07 &lt; jurians&gt; SpiffyJr DASPRiD actually I think Twitter will head over to OAuth2 soon enough /offtopic
20:54:08 &lt; DASPRiD&gt; weierophinney, are you autom-completing on the last guy typing?
20:54:10 &lt; PadraicB&gt; I'll peek at OAuth 1 at the weekend and look into beating it back into shape... I kind of need it here!
20:54:14 &lt;weierophinney&gt; Spabby1: it looks like consensus is ZendService\OAuth and ZendService\OAuth2
20:54:24 &lt; PadraicB&gt; Wherever it ends up...
20:54:24 &lt;weierophinney&gt; DASPRiD: :-P
20:54:38 &lt; Spabby1&gt; super, I have a github repo with oauth2, we can pull it across once ZendService namespace created
20:54:40 &lt; Akrabat&gt; weierophinney: +1
20:54:46 &lt; DASPRiD&gt; (i tend to only use one letter for auto completion ;))
20:54:54 &lt; ocramius&gt; would they already be modules or just libs?
20:54:58 &lt; ocramius&gt; I didn't get that
20:55:02 &lt; Akrabat&gt; ocramius: libs
20:55:04 &lt; ocramius&gt; ok
20:55:05 &lt; PadraicB&gt; ocramius, libraries...right?
20:55:09 &lt; Spabby1&gt; PadraicB: would it be difficult to move to ZendService\OAuth\Client for consistancy even tho we won't ever do a server?
20:55:22 &lt; PadraicB&gt; Spabby1, sure - consistency is good
20:55:36 &lt;weierophinney&gt; Spabby1: they'd each get their own repo -- just a different name for the repo, really.
20:55:40 &lt; SpiffyJr&gt; Can we not use Oauth and then Oauth1 instead?
20:55:46 &lt;weierophinney&gt; ocramius: just libraries
20:55:55 &lt; Akrabat&gt; I'd rather Oauth1 and Oauth2
20:56:01 &lt; SpiffyJr&gt; Oauth 2 is going to be the standard and, I assume, Oauth1 eventually deprectaed
20:56:01 &lt; Gabriel403&gt; Akrabat: +1
20:56:07 &lt; mattcockayne&gt; Akrabat: +1
20:56:11 &lt; Spabby1&gt; agreed Akrabat
20:56:12 &lt;weierophinney&gt; Akrabat: +1
20:56:15 &lt; SpiffyJr&gt; Oh fine.
20:56:16 &lt; SpiffyJr&gt; Be that way.
20:56:23 &lt; Spabby1&gt; we dont even have a ZendService namespace yet mind
20:56:23 &lt; PadraicB&gt; SpiffyJr - no. I'd prefer numbering or leaving 1.0 unnumbered. Anything else would be confusing probably
20:56:24 &lt;weierophinney&gt; Maybe OAuthV1 and OAuthV2?
20:56:31 &lt; SpiffyJr&gt; Don't come crying to me when you get tired of typing 2 all the time!
20:56:33 &lt;weierophinney&gt; so the number is known to be a version of the spec?
20:56:47 &lt; ocramius&gt; the name for OAuth 2.0 is OAuth2 :)
20:56:55 &lt; Spabby1&gt; they are actually named OAuth and OAuth2
20:56:55 &lt; Gabriel403&gt; is there a v3 in the pipe?
20:56:56 &lt;weierophinney&gt; ocramius: fine. :)
20:56:59 &lt; SpiffyJr&gt; Oh
20:57:07 &lt; SpiffyJr&gt; If those are the actual names then we should use them
20:57:11 &lt; SpiffyJr&gt; Oauth and Oauth2
20:57:11 &lt; Spabby1&gt; thats the names of the standards
20:57:15 &lt; PadraicB&gt; Gabriel403, nope - not for a long time I hope...
20:57:30 &lt;weierophinney&gt; kk
20:57:31 &lt; ocramius&gt; this actually makes me think...
20:57:33 &lt;weierophinney&gt; new consensus:
20:57:39 &lt;weierophinney&gt; * ZendService\OAuth for v1 spec
20:57:41 &lt; ocramius&gt; do we need to port oauth 1.0 to zf2?
20:57:48 &lt; ocramius&gt; I mean... is there new stuff?
20:57:48 &lt;weierophinney&gt; * ZendService\OAuth2 for v2 spec
20:57:49 &lt; Akrabat&gt; ocramius: yes
20:57:53 &lt; Spabby1&gt; ocramius: we do if we want to support Twitter
20:57:55 &lt; Spabby1&gt; therefore we do
20:57:55 &lt;weierophinney&gt; ocramius: yes, we've gone through this: twitter uses v1
20:57:57 &lt; Gabriel403&gt; ocramius: twitter uses it
20:57:58 &lt; Akrabat&gt; ocramius: for Twitter
20:58:02 &lt; SpiffyJr&gt; +1 weierophinney
20:58:06 &lt; ocramius&gt; yes, but zf1 has it :)
20:58:07 &lt; cgmartin&gt; sounds good
20:58:07 &lt; SpiffyJr&gt; ocramius, I already updated Oauth for ZF2
20:58:12 &lt; ocramius&gt; ok
20:58:16 &lt; SpiffyJr&gt; ocramius, well, as of beta 2 I think
20:58:24 &lt; SpiffyJr&gt; Unless HTTP/URI was changed it should still work
20:58:28 &lt;weierophinney&gt; ocramius: right, but you can't install it separately from ZF1; with ZF2, you can.
20:58:32 &lt; PadraicB&gt; ocramius, yes...and the work is already done by SpiffyJr
20:58:42 &lt; ocramius&gt; okay :)
20:58:43 &lt; Spabby1&gt; PadraicB: you taking the moving of OAuth and I'll continue with OAuth2?
20:58:50 &lt;weierophinney&gt; Spabby1: still works -- travis tests it regularly
20:58:57 &lt; Spabby1&gt; :P
20:58:58 &lt; SpiffyJr&gt; weierophinney, that one was for me?
20:58:59 &lt; Akrabat&gt; ocramius: ZF1 doesn't distribute separate components
20:59:00 &lt; PadraicB&gt; Spabby1, I believe so
20:59:00 &lt; SpiffyJr&gt; ;)
20:59:03 &lt;weierophinney&gt; dammit, yes.
20:59:05 &lt; SpiffyJr&gt; lol
20:59:07 &lt; Spabby1&gt; :D
20:59:18 &lt;weierophinney&gt; I'm going to refer to you both as Sp from now on.
20:59:18 &lt; SpiffyJr&gt; New agenda: all in favor of Spabby renaming to Sabby
20:59:20 &lt; SpiffyJr&gt; +1!
20:59:20 &lt; ocramius&gt; Akrabat: yeah, not a big issue to me to keep zf1 anyway ;) but I get the point
20:59:21 &lt; Spabby1&gt; I'll change my name to Spibby if it helps
20:59:23 &lt; PadraicB&gt; Less tabbing, oh Benevolent One ;)
20:59:25 &lt; cgmartin&gt; haha
20:59:27 &lt; ocramius&gt; lol
20:59:42 &lt; jurians&gt; used Zend\Oauth last week with Twitter service (and patched it) so it's confirmed it works atm ;)
20:59:45 &lt; Akrabat&gt; it's having to the third character before pressing tab that's the problem
21:00:01 &lt;weierophinney&gt; kk, I'm calling it a day -- we're right at an hour, and we got a lot discussed, voted on, and agreed upon. Much better than last week. :)