text: <ac:macro ac:
  <h2>Information</h2>
  <ul>
  <li>Date: 09 Nove, 23 November 2011, 17:00 UTC</ac:link-body></ac:link></li>
  </ul>
  <h2>Summary</h2>
  <h3>Mail RFC</h3>
  <p>Matthew posted an <ac:link><ri:page ri:<ac:link-body>RFC on the Mail component</ac:link-body></ac:link>, and has received a fair bit of feedback already on the list. We discussed several pieces of feedback:</p>
  <ul>
  <li>Email validation in the Address objects should be possible, but opt-in. In most cases, you'll have already done email validation, so this would be unwanted overhead. However, having the option makes sense.</li>
  <li>Somebody suggested the "Attachments" class should be renamed to "AttachmentCollection".</li>
  <li>Artur suggested renaming "Mailer" to "Transport", to better indicate the responsibility.</li>
  <li>Ralph was concerned about the main consumable being a level deeper than the component namespace. Considering how few transports we will likely have, it makes sense to keep them top-level in the namespace to promote common usage patterns.</li>
  <li>Shahar suggested that there is likely a lot of affinity and similarity between the Message objects and the way HTTP request/response objects are structured and handled. Both aggregate headers and content, and both allow for multi-part bodies with a mix of strings and stream content.</li>
  </ul>
  <p>General consensus is that the proposed design looks reasonable. We decided to put off the question of a common "Message" component on which Mail and Http would depend until Shahar and/or Ralph can better prototype how they envision handling multi-part and/or stream content bodies in messages/requests/responses; this will better show the complexities involved, as well as expose the extent of the commonalities they may share.</p>
  <p><strong>tl;dr:</strong> The Mail RFC was approved, but may have additional changes in the future.</p>
  <h3>Log RFC</h3>
  <p>Benoît Durand (nickname intiilapa) posted an <ac:link><ri:page ri:<ac:link-body>RFC on Log refactoring</ac:link-body></ac:link> last week as part of the beta2 effort. Discussion was light, but exposed the following comments:</p>
  <ul>
  <li>The "Logger" as indicated on the RFC should be renamed "LoggerCollection".</li>
  <li>The "Handler" as indicated on the RFC should be renamed "Logger". These are individual classes capable of generating/interacting with logs. A LoggerCollection would compose one or more of these.</li>
  <li>The RFC discusses making an explicit API around log levels instead of relying on <code>__call()</code>. However, one capability of the original log component was the ability to specify custom log levels, which many would like to see continue. The RFC should be updated to indicate how this support would work.</li>
  <li>The RFC should better detail how filters, formatters, and loggers are attached to their respective consumers (i.e., spell out if/how plugins will be implemented).</li>
  <li>The RFC should detail how one might access individual loggers in a LoggerCollection.</li>
  </ul>
  <p>Overall, consensus is that development can begin with these changes, but that there may be additional feedback once code is in place. (Matthew indicated that this is expected during the beta cycle.)</p>
  <h3>CLI RFC</h3>
  <p>The final topic was the <ac:link><ri:page ri:<ac:link-body>CLI RFC</ac:link-body></ac:link>, proposed by Robert Basic (nickname robertbasic).</p>
  <p>Discussion started first with Robert apologizing that he created the RFC, but then found himself in a situation with little time to devote towards it. We reassured him that plenty of folks are interested in assisting with this functionality.</p>
  <p>Moving on, the following points came up:</p>
  <ul>
  <li>The proposal needs a section detailing architecture: what interfaces it will define and use.</li>
  <li>The proposal needs a section detailing how the component will be consumed (usage section)</li>
  <li>There's some confusion by people reviewing it about the distinction between the Cli and Console components; this needs to be better fleshed out in usage examples and the narrative.</li>
  <li>We need a proof-of-concept or prototype that attempts to use MVC artifacts in a CLI environment, to see if the MVC is truly request agnostic, or if we'll need to program CLI-specific controllers.</li>
  <li>Zend\Tool will likely be able to be deprecated, with the project creation/manipulation tooling becoming a separate module consumed by the Cli component.</li>
  </ul>
  <p>Consensus is that the RFC is not yet ready for approval, but prototyping should (and has!) begin to iron out some of the issues, as well as to provide some usage examples.<">
  Nov 09 17:01:22 <weierophinney> So, agenda for today:
  Nov 09 17:01:26 <weierophinney>
  Nov 09 17:01:36 <weierophinney> First item: mail rfc
  Nov 09 17:02:01 <weierophinney> Anybody want to discuss?
  Nov 09 17:02:33 <robertbasic> I remember there was a discussion about the Address, should it validate or not the email
  Nov 09 17:02:34 <weierophinney> The one change that I'll likely make is to s/Mailer/Transport/ to go along with current ZF design, as well as to be more explicit.
  Nov 09 17:02:43 <robertbasic> but can't remember what was the final decision on it
  Nov 09 17:03:02 <weierophinney> robertbasic, I think we can make that opt-in pretty easily.
  Nov 09 17:03:47 <robertbasic> weierophinney: like, if there is a validator registered, validate it, if not, don't?
  Nov 09 17:03:57 <weierophinney> robertbasic, exactly.
  Nov 09 17:04:02 <robertbasic> fine by me
  Nov 09 17:04:27 <weierophinney> Often, you'll be pulling emails out of some sort of persistent storage anyways, in which case you'll likely have validated them already.
  Nov 09 17:04:55 <robertbasic> right
  Nov 09 17:05:14 <weierophinney> The other change suggested that I agreed with was s/Attachments/AttachmentCollection/
  Nov 09 17:06:09 <ralphschindler> question on the mailer/transport thing, it sounds like there is no top level mailer then, b/c transport is a backend specific adapter currently
  Nov 09 17:06:14 <weierophinney> Any other issues/discussion points with the mail rfc? (again, url is)
  Nov 09 17:06:42 <weierophinney> shevron, I believe you suggested we have some sort of common base between the Mail and HTTP headers?
  Nov 09 17:06:48 <ralphschindler> i was anticipating $mailer = new Mailer($transport = null) // transport is SMTP, Sendmail, etc
  Nov 09 17:07:01 <ralphschindler> transport by default would be sendmail i assume
  Nov 09 17:07:02 <shevron> weierophinney: indeed
  Nov 09 17:07:29 <weierophinney> ralphschindler, why? the transport object is what you pass Message objects to. There's no need for a wrapper.
  Nov 09 17:07:32 <shevron> weierophinney: also, there are common features between handling the message body between HTTP and MIME
  Nov 09 17:07:55 <weierophinney> shevron, makes sense. Where would you anticipate pushing that code?
  Nov 09 17:08:01 <ralphschindler> so then a mailer is either Zend\Mail\Smpt or Zend\Mail\Sendmail ?
  Nov 09 17:08:13 <weierophinney> ralphschindler, yes
  Nov 09 17:08:34 <weierophinney> or a layer deeper: Zend\Mail\Transport\Smtp, etc.
  Nov 09 17:08:55 <shevron> weierophinney: could be Zend\Stdlib, it doesn't really fall under the old Zend\Mime category
  Nov 09 17:09:13 <weierophinney> shevron, maybe a Zend\Message component?
  Nov 09 17:09:38 <ralphschindler> ok, that is what i was getting at, the primary interface for sending mail is one level deep in the namespace, as opposed to an adapter approach
  Nov 09 17:09:39 <shevron> weierophinney, yes, it's possible - if so, we can also move the Message \ RequestDescription etc. interfaces there
  Nov 09 17:09:59 <weierophinney> ralphschindler, the point is that the one object you might be passing around or configuring in the DI container/SL is a transport. I'm ambivalent about whether we push it down a level or not.
  Nov 09 17:10:00 <shevron> from Stdlib
  Nov 09 17:10:07 <weierophinney> shevron, yep.
  Nov 09 17:10:25 <weierophinney> what do folks think about shevron's suggestions?
  Nov 09 17:10:39 <weierophinney> DASPRiD? EvanDotPro? ralphschindler?
  Nov 09 17:11:03 <weierophinney> ralphschindler, the interface would still be at the top-level of the component; it's where we put the implementations of that interface.
  Nov 09 17:11:20 <weierophinney> and for as few transports as we have, top-level is probably fine.
  Nov 09 17:11:40 <robertbasic> wouldn't it be a bit "funny" if we have a Zend\Message and leave Zend\Stdlib\Response?
  Nov 09 17:12:21 <robertbasic> not that I'm against it, just curious
  Nov 09 17:12:23 <ralphschindler> weierophinney: thats fine actually
  Nov 09 17:12:35 <shevron> one more point I want to add is that we need to abstract out the message body for both Mail and Http - a body should be passed to the transport (of both Mail and Http) not as a string but as an object with a MessageEntity / Readable / Writable interfaces. This will allow handling things such as streams, multipart attachments etc. in a memory efficient way
  Nov 09 17:12:36 <ralphschindler> im not sure i understand shevron's suggestion?
  Nov 09 17:12:36 <weierophinney> robertbasic, I think he's suggesting that we move Response/Request into Message as well.
  Nov 09 17:13:05 <robertbasic> weierophinney: oh ok then
  Nov 09 17:13:15 <shevron> ralphschindler: I'm saying there is a lot of code that could be shared between the Http Request / Response classes and the Mail message classes
  Nov 09 17:13:27 <weierophinney> ralphschindler, he's suggesting we have a component around the Message, which encapsulates both headers and content, and on which both HTTP and Mail would build.
  Nov 09 17:13:49 <robertbasic> (as for the rest of it, I'm not quite familiar with the MIME part, so I'll just agree
  )
  Nov 09 17:14:03 <weierophinney> ralphschindler, to do things like handling multipart, handling streams, etc.
  Nov 09 17:14:57 <ezimuel> we have to estimate the code in common between HTTP and MIME to move the Request/Response under the Stdlib
  Nov 09 17:15:24 <ralphschindler> i agree with ezimuel
  Nov 09 17:15:25 <ezimuel> or we can abstract the common parts
  Nov 09 17:15:34 <shevron> I'll give an example use case: a multipart MIME message which contains both text and a large attachment is quite similar to an HTTP request which contains both form data and a file upload. Almost same format, same issues (memory efficiency)
  Nov 09 17:15:53 <ralphschindler> i think we need to see the overall gain at the cost of the new dependency
  Nov 09 17:16:00 <weierophinney> ezimuel, ralphschindler, he's suggesting not under stdlib, but a "message" component. And yes, there needs to be some evaluation of how much can be abstracted.
  Nov 09 17:16:24 <shevron> I agree, I'm not 100% it's woth it either, but it needs to be evaluated
  Nov 09 17:16:49 <weierophinney> ralphschindler, he's actually trying to address a specific concern you've brought up, and that's handling/utilizing streams as message content.
  Nov 09 17:17:06 <weierophinney> and that part is going to be similar between both components.
  Nov 09 17:17:18 <shevron> weierophinney: not only simple streams, but also a body made out of mixed streams and string buffers
  Nov 09 17:17:23 <weierophinney> maybe we should defer that part until the initial implementation is in place?
  Nov 09 17:17:28 <ralphschindler> right- perhaps we should throw together a quick prototype to get a sense of the complexity
  Nov 09 17:17:30 <shevron> as in my example above
  Nov 09 17:17:32 <ezimuel> so Message will be the general (abstract class) with specific implementations like HTTP and MIME?
  Nov 09 17:17:58 <shevron> ezimuel: yes, I think so - but again it needs to be evaluated
  Nov 09 17:18:10 <ezimuel> make sense to me
  Nov 09 17:18:20 <ralphschindler> php itself has a robust interface for stream data (and it has an interface for bridging a class to a stream) so i'd like to see how complex the code is to wire that up
  Nov 09 17:19:16 <weierophinney> kk. So: action steps: Get the Mail component coded per the RFC, and then discuss abstracting the Message to be utilized by both HTTP and Mail later?
  Nov 09 17:19:38 <robertbasic> weierophinney: +1
  Nov 09 17:19:52 <ralphschindler> +1
  Nov 09 17:19:57 <ezimuel> +1
  Nov 09 17:19:59 <shevron> weierophinney: +1, also I can write a prototype based on the HTTP client requirements
  Nov 09 17:20:12 <shevron> and we can evaluate how they fit MIME
  Nov 09 17:20:43 <weierophinney> shevron, cool
  Nov 09 17:20:56 <weierophinney> any other concerns/discussion on the Mail RFC?
  Nov 09 17:21:24 <robertbasic> not from me.
  Nov 09 17:21:36 <weierophinney> If not, then we'll move on. I'm going to skip the CLI RFC for the moment to move on to another beta2 RFC, Log:
  Nov 09 17:23:41 <weierophinney> My initial comments are that I'd like to differentiate loggers (something generating a log) from aggregates (something aggregating many loggers)
  Nov 09 17:23:55 <weierophinney> Basically, s/Logger/LoggerAggregate/ and s/Handler/Logger/ in the proposal.
  Nov 09 17:24:19 <shevron> weierophinney: as long as I can directly use a logger, I like that idea
  Nov 09 17:24:24 <weierophinney> Also, one item that is omitted is the idea of registering custom log levels, and logging to them.
  Nov 09 17:24:28 <weierophinney> shevron, that would be the idea.
  Nov 09 17:24:31 <shevron> (and don't need to attach it to an aggregate)
  Nov 09 17:24:43 <robertbasic> +1 for custom log levels
  Nov 09 17:24:48 <weierophinney> Is intiilapa around?
  Nov 09 17:25:01 <weierophinney> nope, he's not.
  Nov 09 17:25:25 <weierophinney> jurians, you added this agenda item... anything you want to discuss or comment on?
  Nov 09 17:25:42 <jurians> weierophinney: that was just because the rfc was made and not on the agenda
  Nov 09 17:25:48 <jurians> but +1 for the custom log levels
  Nov 09 17:26:03 <jurians> can we, like caching, also put an event manager in place?
  Nov 09 17:26:51 <robertbasic> weierophinney: LoggerAggregate or LoggerCollection?
  Nov 09 17:27:34 <robertbasic> as there was MessageCollection for the Mail
  Nov 09 17:27:35 <weierophinney> robertbasic, LoggerCollection
  Nov 09 17:27:54 <robertbasic> so I'm not sure is it my Engrish or that those 2 are basically the same
  Nov 09 17:27:54 <weierophinney> I used "aggregate" as that was what intiilapa had written originally.
  Nov 09 17:28:08 <weierophinney> jurians, put an event manager in place... where?
  Nov 09 17:28:39 <robertbasic> weierophinney: ah ok.
  Nov 09 17:29:03 <weierophinney> jurians, my understanding is he plans to write a listener to which you would attach a logger instance, and then attach that to an event if you want to provide logging – is that what you're getting at?
  Nov 09 17:29:38 <jurians> mz, i need to read that a second time
  Nov 09 17:30:13 <jurians> yep, I think so
  lol
  Nov 09 17:30:17 <weierophinney> LOL
  Nov 09 17:30:19 <weierophinney> cool.
  Nov 09 17:30:26 <robertbasic> also, the writers/handlers/filters should be pluggable, no?
  Nov 09 17:30:26 <weierophinney> Any other discussion on the log rfc?
  Nov 09 17:30:31 <weierophinney> robertbasic, yes
  Nov 09 17:30:50 <jurians> the rfc is not that detailed afaik
  Nov 09 17:31:06 <jurians> after the initial work, people might raise some other concerns
  Nov 09 17:31:07 <weierophinney> robertbasic, handlers become loggers, and could be optionally attached to a logger collection. filters and formatters would be pluggable, just as they are now, but using the plugin broker, iirc
  Nov 09 17:31:17 <robertbasic> that is to use the new plugin loader/broker thingy
  Nov 09 17:31:19 <weierophinney> jurians, likely. THat's why it's scheduled for an early beta
  Nov 09 17:31:27 <jurians> so: do we need to get the rfc more detailed or can intiilapa make a prototype?
  Nov 09 17:31:28 <jurians> kk
  Nov 09 17:31:40 <weierophinney> jurians, I think the rfc is mostly to outline what changes he felt should be made to the current system.
  Nov 09 17:32:02 <robertbasic> weierophinney: but loggers can be pluggable too, no?
  Nov 09 17:32:07 <weierophinney> if we think those changes look okay, we give him the green light, and we incorporate feedback as he works on it and after the beta.
  Nov 09 17:32:19 <weierophinney> robertbasic, yes, in the logger collection they'd be pluggable.
  Nov 09 17:32:20 <Asgrim> +1 custom log levels
  Nov 09 17:32:21 <jurians> seems like a plan
  Nov 09 17:32:24 <weierophinney> (as they are now)
  Nov 09 17:32:30 <robertbasic> weierophinney: ah ok
  Nov 09 17:33:03 <robertbasic> +1 then from me on this
  Nov 09 17:33:38 <weierophinney> To sum up:
  Nov 09 17:33:48 <weierophinney> * s/Logger/LoggerCollection/
  Nov 09 17:33:52 <weierophinney> * s/Handler/Logger/
  Nov 09 17:34:10 <weierophinney> * Address custom log levels and how they are invoked (will __call() be available for those?)
  Nov 09 17:34:20 <Asgrim> surely collection != aggregate? collection is (1, 2, 3) aggregate is (6)? I may be wrong though
  Nov 09 17:34:38 <weierophinney> * Detail how the formatters, filters, loggers are attached
  Nov 09 17:35:27 <weierophinney> Asgrim, they're synonyms in natural language. But an aggregate in OOP often details an object that collects a number of other objects but implements the same interface.
  Nov 09 17:35:36 <jurians> About that "Detail how..": I'm fine with a "usage" section like the mail rfc
  Nov 09 17:35:53 <weierophinney> Asgrim, so, you can call ->log() on the aggregate or any of the objects it composes.
  Nov 09 17:36:02 <weierophinney> jurians, kk, I'll note that.
  Nov 09 17:36:41 <Asgrim> weierophinney Ok fine
  Nov 09 17:36:48 <jurians> weierophinney: but you might want to call log() to the collection and/or to a single logger as well?
  Nov 09 17:37:34 <weierophinney> jurians, yes. And you can do that by either using filters (which are how an individual logger indicates what it's interested in) or pulling out the individual logger.
  Nov 09 17:37:38 <weierophinney> Another note:
  Nov 09 17:37:46 <weierophinney> * Detail how access to individual loggers would work
  Nov 09 17:38:35 <weierophinney> any more discussion on this RFC?
  Nov 09 17:38:43 <jurians> yes, those five points are ok; +1
  Nov 09 17:38:58 <robertbasic> weierophinney: +1
  Nov 09 17:39:08 <jurians> (brb)
  Nov 09 17:40:03 <weierophinney> kk, next topic
  Nov 09 17:40:18 <weierophinney> CLI RFC:
  Nov 09 17:40:22 <robertbasic> about that
  Nov 09 17:40:23 <weierophinney> robertbasic, TAKE IT AWAY!
  Nov 09 17:40:38 <DASPRiD> it's a trap! :x
  Nov 09 17:40:52 <robertbasic> first, I have to say that I don't have as much free time as I wanted
  Nov 09 17:41:09 <robertbasic> which means that I'm not able to develop at pace which would suit the community
  Nov 09 17:41:28 <robertbasic> as for example EvanDotPro waits for the cli to be done so he can work on the module install stuff
  Nov 09 17:41:47 <robertbasic> so, if anyone wants to take away the main dev, feel free
  Nov 09 17:41:54 <weierophinney> robertbasic, I think that's okay. If we have a good RFC with a clear architecture, then somebody else can lead the development.
  Nov 09 17:42:01 <weierophinney> I think there are plenty of folks willing to help out.
  Nov 09 17:42:20 <robertbasic> of course, I'd be still around to test/fix/bug people
  Nov 09 17:42:32 <robertbasic> I just don't want to make people wait
  Nov 09 17:42:53 <robertbasic> I'll also fire this away to the ML later tonight
  Nov 09 17:43:09 <robertbasic> I'm not sure how mattcockayne is with time
  Nov 09 17:43:22 <robertbasic> maybe he'll be willing to take on the leading
  Nov 09 17:43:30 <weierophinney> robertbasic, I think either myself or ralphschindler may be willing to help out as well.
  Nov 09 17:43:42 <robertbasic> weierophinney: oh, that'd be pure awesome
  Nov 09 17:43:46 <weierophinney> so... with that out of the way – any discussion on the actual RFC?
  Nov 09 17:44:10 <DASPRiD> "willing to help out" <-- you are paid for that
  Nov 09 17:44:11 <robertbasic> what's it missing? should I add a "proposed architecture" too?
  Nov 09 17:44:29 <weierophinney> DASPRiD, yes, but I also have a lot of other stuff to work on.
  Nov 09 17:44:35 <weierophinney> robertbasic, yes, I think so.
  Nov 09 17:44:46 <DASPRiD> weierophinney, simple solution: pay a few other guys to do it
  Nov 09 17:44:50 <weierophinney> create an outline of interfaces you may need
  Nov 09 17:44:52 <ralphschindler> i think we need to decide the scope of it vs. the idea of a console and how Zend\Tool fits in
  Nov 09 17:44:59 <ralphschindler> i think simpler the better
  Nov 09 17:45:16 <ralphschindler> Zend\Tool has levels of abstraction taht we find we no longer need
  Nov 09 17:45:27 <robertbasic> ralphschindler: well, my initial idea was to build Zend\Tool on top of these 2 cli components
  Nov 09 17:45:45 <robertbasic> well, at least on top of Zend\Console
  Nov 09 17:45:54 <ralphschindler> im fine saying that all interfaces for Zend\Tool are cli in nature
  Nov 09 17:46:22 <ralphschindler> (previously there was abstraction in case you wanted to have a web client or xml/json-rpc client)
  Nov 09 17:46:24 <robertbasic> oh, question. the naming, Zend\Console for the "low level" and Zend\Cli for the "higher" level?
  Nov 09 17:46:46 <ralphschindler> whats the difference between Console and Cli ?
  Nov 09 17:47:12 <robertbasic> Zend\Console is a bit improved/refactored Zend\Console\Getopt
  Nov 09 17:47:31 <Asgrim> about the flag mentioned at the end - would it not make sense to say controller is HTTP only, CLI only or HTTP+CLI accessible?
  Nov 09 17:47:33 <robertbasic> while Zend\Cli would be more like Zend\Mvc with the Bootstrap, Application, Router(s)....
  Nov 09 17:48:21 <ezimuel> mh, i'm confused
  Nov 09 17:48:22 <robertbasic> of course, these are only "in-work" namings, can be changed
  Nov 09 17:48:35 <robertbasic> ezimuel: with what?
  Nov 09 17:48:37 <ezimuel> to me seems that Zend\Console and Zend\Cli are quite similar
  Nov 09 17:49:18 <robertbasic> ezimuel: yes, but with Zend\Console, the low level stuff, you can build one off console scripts which wouldn't need to depend on other parts of the ZF
  Nov 09 17:49:39 <robertbasic> while with Zend\Cli you'd build modules that are accessible from the console
  Nov 09 17:49:45 <ocramius> If I can ask... I often find myself creating scripts that replicate 90% of index.php for CLI purposes... Would Zend\Cli solve that somehow? It would be nice if the directory structure allowed to support bootstrapping from a single entry point and then use bootstrapped application in either cli or index...
  Nov 09 17:50:09 <robertbasic> ocramius: most likely will end up with a bin/zf2.php script of some sort
  Nov 09 17:50:11 <leedavis81__> I understood it that Zend\Cli tasks / applications consumed Zend\Console which took care of arg passing etc.
  Nov 09 17:50:22 <DASPRiD> heh yeah, i always find myelf to write some base bootstrap class for cli i always include in my cli scripts then
  Nov 09 17:50:33 <robertbasic> leedavis81__: yes, something like that
  Nov 09 17:50:44 <robertbasic> DASPRiD: that's where Zend\Cli comes in, takes care of that
  Nov 09 17:50:55 <DASPRiD> <3
  Nov 09 17:51:03 »» robertbasic gives DASPRiD bacon
  Nov 09 17:51:16 <DASPRiD> \o/
  Nov 09 17:51:23 <robertbasic> also, DASPRiD don't be so happy, you'll be doing the cli routing stuff
  Nov 09 17:51:33 <robertbasic> helping out, at least
  Nov 09 17:51:45 <DASPRiD> robertbasic, how do you know?
  Nov 09 17:51:45 <robertbasic> ezimuel: did I make it any clearer now?
  Nov 09 17:51:45 <leedavis81__> The requirement for Zend\Console providing functionality for capturing / defining an environment...
  Nov 09 17:51:54 <leedavis81__> Do we need this? Should it not be part of the Zend\Cli application to ensure its existence (if required)?
  Nov 09 17:52:03 <ezimuel> robertbasic: ok, maybe I was confused by the name, now it's more clear.
  Nov 09 17:52:04 <Asgrim> would you ever want to use Zend\Cli without Zend\Console?
  Nov 09 17:52:08 <leedavis81__> I imagine some light cli tasks that may not need to know about the application environment.
  Nov 09 17:52:27 <robertbasic> leedavis81__: that... that was proposed by mattcockayne, not really understanding it yet myself
  Nov 09 17:52:44 <robertbasic> ezimuel: cool. as I said, open to different namings
  Nov 09 17:53:22 <robertbasic> Asgrim: if you want to use some other component for argument parsing, yes. but that should be injectable via DI
  Nov 09 17:53:30 <ezimuel> robertbasic: maybe Zend\Cli can become a subclass of Zend\Console, like Zend\Console\Params or something like that
  Nov 09 17:53:58 <Asgrim> robertbasic, swish
  Nov 09 17:54:00 <robertbasic> ezimuel: Zend\Console\Application?
  Nov 09 17:54:51 <robertbasic> as Params (or similar) would be a container of some sort which will hold the parsed arguments, and those will be than passed on to the CliRequest object which again will be used in the controllers
  Nov 09 17:55:01 <robertbasic> right, this RFC needs improvement
  Nov 09 17:55:03 <ezimuel> robertbasic, ops I inverted the naming: Zend\Console is the basic class that manage the params, right?
  Nov 09 17:55:12 <robertbasic> ezimuel: yes
  Nov 09 17:55:19 <DASPRiD> robertbasic, i can surely help you out about the cli routing if there are any questions, but…
  Nov 09 17:56:00 <robertbasic> DASPRiD: I imagine it something like a light version of the Segment in HTTP routing
  Nov 09 17:56:06 <robertbasic> I think it's the Segment
  Nov 09 17:56:35 <robertbasic> ezimuel: so you mean to have the parsing as a subclass of zend\cli and have only one component?
  Nov 09 17:56:44 <ralphschindler> so, some background: we've done a ton of work anticipating this already (at what i'd consider substantial cost), the interfaces in Stdlib are cli/web/http agnostic, and we are using those throughout Zend\Mvc already, so the plan was that (if feasible) Zend\Mvc* can work in a cli and http based enviornment
  Nov 09 17:57:10 <ezimuel> robertbasic: yes, the "parser of params" is a subclass of the "application console"
  Nov 09 17:57:11 <ralphschindler> i think need to work towards that and see if its really possible
  Nov 09 17:57:11 <ralphschindler> if its not, there's little value in the Stdlib\Request & Response & Message interfaces
  Nov 09 17:57:13 <ralphschindler> b/c this was their purpose
  Nov 09 17:57:37 <weierophinney> ralphschindler, which was why Console\Application would return a RouteMatch – that's what we're typically looking at in controllers.
  Nov 09 17:57:51 <ralphschindler> so we should, out of the gate, try and prototype a cli that works on Zend\Mvc (dispatcher)
  Nov 09 17:57:52 <DASPRiD> robertbasic, we should talk about it as soon as you are starting with it
  Nov 09 17:58:14 <robertbasic> ralphschindler: link in a sec
  Nov 09 17:58:20 <leedavis81__> So, does the project setup stuff in Zend\Tool become a Zend\Console application?
  Nov 09 17:58:22 <ralphschindler> does that sound reasonable?
  Nov 09 17:58:32 <robertbasic> ralphschindler: see my prototype
  Nov 09 17:58:40 <weierophinney> leedavis81__, yes, likely a module.
  Nov 09 17:58:41 <ralphschindler> leedavis81__: the Zend\Tool\Console stuff, but not the Zend\Tool\Project stuff
  Nov 09 17:58:41 <robertbasic> leedavis81__: no it does not
  Nov 09 17:58:51 <weierophinney> leedavis81__, nevermind, I defer to robertbasic
  Nov 09 17:59:01 <DASPRiD> I actually wonder why we are type hinting on the stdlib requestdescription in the router: it offers nothing actually
  Nov 09 17:59:03 <ezimuel> ralphschindler: right, I think we have some overlapping to check
  Nov 09 17:59:13 <robertbasic> weierophinney: leedavis81__ well, probably a module built with Zend\Cli
  Nov 09 17:59:20 <weierophinney> DASPRiD, ralphschindler has an idea on that, btw.
  Nov 09 17:59:27 <DASPRiD> weierophinney, orly?
  Nov 09 17:59:28 <weierophinney> robertbasic, that's what I was getting at.
  Nov 09 17:59:41 <weierophinney> DASPRiD, query him after the meeting. We discussed it today during our meeting.
  Nov 09 17:59:42 <robertbasic> DASPRiD: ok, will talk on it in #zftalk.2
  Nov 09 17:59:51 <DASPRiD> weierophinney, kay
  Nov 09 18:00:16 <robertbasic> ezimuel: getting back at you, if we make the parser a subclass, then it won't be easy to use only the parser without all the Zend
  Nov 09 18:00:18 <robertbasic> gah
  Nov 09 18:00:28 <robertbasic> *without all the Zend\Cli\Application stuff
  Nov 09 18:00:33 <weierophinney> So, let me summarize, then:
  Nov 09 18:00:50 <weierophinney> * robertbasic likely cannot spearhead development, but there are folks waiting in the wings to assist.
  Nov 09 18:01:20 <weierophinney> * there's still some work to do on the proposal – deciding whether we need a differentiation between Cli and Console, and, if so, documenting what the differences in focus are.
  Nov 09 18:01:45 <weierophinney> * we likely need to figure out if we can really have an MVC that's agnostic of mvc vs console usage.
  Nov 09 18:01:52 <intiilapa> Hello
  Nov 09 18:02:04 <weierophinney> Does that sound about right?
  Nov 09 18:02:07 <weierophinney> intiilapa, you're an hour late.
  Nov 09 18:02:13 <ezimuel> I think we have to check the overlapping, if three are, between Zend\Tool, Zend\Console and Zend\Cli
  Nov 09 18:02:22 <robertbasic> weierophinney: yes
  Nov 09 18:02:23 <intiilapa> weierophinney: why?
  Nov 09 18:02:29 <intiilapa> damned winter time >_<
  Nov 09 18:02:34 <leedavis81__>
  )
  Nov 09 18:02:35 <robertbasic> I'll try to update the RFC as fast as I can
  Nov 09 18:02:35 <weierophinney> intiilapa, because 17:00 UTC was an hour ago.
  Nov 09 18:03:04 <weierophinney> ezimuel, it sounds like Tool mainly provides functionality invoked by a cli/console component at this time.
  Nov 09 18:03:25 <weierophinney> ezimuel, and cli/console may or may not have overlapping responsibilities – that's the real part we need to determine.
  Nov 09 18:03:31 <leedavis81__> there's a countdown clock on the metting agenda page
  Nov 09 18:03:37 <robertbasic> they shouldn
  Nov 09 18:03:47 <intiilapa> weierophinney: I can't comeback one hour earlier during the winter
  Nov 09 18:03:54 <weierophinney> intiilapa, :-/
  Nov 09 18:04:00 <robertbasic> they shouldn't have overlaps, zend\cli should use zend\console
  Nov 09 18:04:31 <ezimuel> ok, maybe the overlapping is only in my mind right now
  Nov 09 18:04:41 <weierophinney> robertbasic, kk – then it needs to be fully clarified with your architectural outline and narrative.
  Nov 09 18:04:59 <robertbasic> ezimuel: weierophinney I'll try to make the RFC much clearer in the coming days
  Nov 09 18:05:13 <robertbasic> (that's why I asked feedback on the rfc before I published it >.<)
  Nov 09 18:05:40 <ezimuel> robertbasic: awesome, and of course i'm available to help in the development
  Nov 09 18:06:01 <robertbasic> also, I'm not saying this is the way it should be done
  Nov 09 18:06:04 <ralphschindler> i think when ezimuel said overlaps, i think he was talking about the abstraction we already have in place, it should be used or tossed if its unnecessary, right ezimuel ?
  Nov 09 18:06:39 <ezimuel> ralphschindler: yes, overlapping of "architectural concepts"
  Nov 09 18:06:56 <weierophinney> cool
  Nov 09 18:07:11 <robertbasic> so first, me updating the rfc
  Nov 09 18:07:52 <weierophinney> robertbasic, yep. And then gathering more feedback, and then starting in earnest on development. Though I think prototyping can start anytime.
  Nov 09 18:07:57 <weierophinney> (and I think you have...)
  Nov 09 18:08:12 <robertbasic> yes, prototype (one of) is
  Nov 09 18:08:34 <robertbasic> other is
  Nov 09 18:08:38 <ralphschindler> here's what i suggest, we make a HelloWorld module, then give it the cli treatment to see how much of an existing http specific module has to change to facilitate a cli interface
  Nov 09 18:09:11 <ralphschindler> that should help us prove if the interfaces for the base things: request response, etc, are sound, does that sound like a plan?
  Nov 09 18:09:30 <DASPRiD> I gotta head out for now, ttyl.
  Nov 09 18:09:33 <ralphschindler> b/c really thats what we'd be asking users to do, like EvanDotPro - how would he introduce cli capabilities to EdpUser
  Nov 09 18:09:35 <robertbasic> DASPRiD: bye!
  Nov 09 18:09:39 <weierophinney> ralphschindler, that sounds reasonable.
  Nov 09 18:09:39 <ralphschindler> see you DASPRiD
  Nov 09 18:09:59 <ezimuel> DASPRiD: bye
  Nov 09 18:10:15 <weierophinney> so, folks, we're in our overflow time now. Any last words before I call the meeting over?
  Nov 09 18:10:32 <robertbasic> yea, sorry for the mess I made
  Nov 09 18:10:37 <ralphschindler> lol
  Nov 09 18:10:41 <ralphschindler> its a good mess
  Nov 09 18:10:51 <ezimuel> robertbasic: no sorry, i like mess
  Nov 09 18:10:55 <ralphschindler> cli has been kicked off offically robertbasic
  Nov 09 18:10:55 <intiilapa> weierophinney: did you vote for RFC Mail and Log?
  Nov 09 18:11:25 <intiilapa> +already
  Nov 09 18:11:31 <weierophinney> intiilapa, yes. They're in – we had a few notes for you that I'll forward along later.
  Nov 09 18:11:31 <robertbasic> intiilapa: what? You still haven't made the Log? We gave you a green light an hour ago
  Nov 09 18:11:46 <intiilapa> robertbasic: :o
  Nov 09 18:11:59 <intiilapa> weierophinney: ok
  Nov 09 18:12:04 <weierophinney> ralphschindler, and it's not a mess – I think having it on the agenda helps keep momentum.
  Nov 09 18:13:07 <robertbasic> that's it then
  Nov 09 18:13:38 <robertbasic> thanks all for the understanding :-/
  Nov 09 18:13:55 <weierophinney> robertbasic, thank you for starting it off in the first place!
  Nov 09 18:14:13 <weierophinney> Okay, folks, that's a wrap! Thanks for coming, and I'll post a summary later today, as well as start the next agenda.
  <<<