15:30:09 <mfer> #startmeeting openstack-sdk-php
15:30:10 <openstack> Meeting started Wed Jun 11 15:30:09 2014 UTC and is due to finish in 60 minutes.  The chair is mfer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:13 <openstack> The meeting name has been set to 'openstack_sdk_php'
15:30:30 <mfer> Welcome everyone. Please state your name along with any applicable associations
15:30:34 <mfer> Matt Farina, HP
15:30:38 <samchoi> Sam Choi, HP
15:30:48 <jamiehannaford> Jamie Hannaford, Rackspace
15:31:18 <mfer> jamiehannaford anyone else from your side of the fence joining us today?
15:31:46 <jamiehannaford> no I don't think so
15:31:53 <jamiehannaford> Glen and Shaunak are at confs
15:32:03 <mfer> ooo, I hope they are having fun
15:32:18 <mfer> #topic agenda
15:32:22 <mfer> #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP
15:32:39 <mfer> 1. Intro to the PHP SDK if there is anyone new? (mfer)
15:32:39 <mfer> 2. Reviews in progress - any questions/concerns? (samchoi)
15:32:39 <mfer> 3. How are we going to handle transport state (like base URLs) for services and resource models? (jamiehannaford)
15:32:39 <mfer> 4. Do `RemoteObject' and `Object' need to be separate classes? (jamiehannaford)
15:32:47 <mfer> anything else we should add or remove from the agenda?
15:33:19 <samchoi> that looks fine to me, it's somewhat shorter than usual so we can have open discussion
15:33:28 <jamiehannaford> I have nothing else to add - we have a few lingering topics on the mailing list
15:33:44 <mfer> ok
15:34:06 <mfer> I think we can skip 1 because we have no one else new. I think for next week we can drop it and address anyone new when we are lucky enough to have them
15:34:17 <mfer> #topic Reviews in progress - any questions/concerns? (samchoi)
15:34:28 <mfer> samchoi since you brought this one up care to kick us off?
15:35:08 <samchoi> mfer, I left it on the agenda primarily in case there were additional concerns about open reviews
15:35:38 <jamiehannaford> does anyone have any objections to https://review.openstack.org/#/c/92280/
15:36:39 <mfer> jamiehannaford two things. 1) I need to give that one more review. It's on my todo list for today. 2) the commit message needs to say what the commit does rather than the last change he made to it.
15:37:03 <samchoi> last I checked the sphinx review, it looked pretty good
15:37:11 <samchoi> I'll take another look today though
15:37:30 <samchoi> that was previously lower on my priorities since it didn't block other work
15:37:31 <jamiehannaford> mfer yeah I agree about commit msg - I don't know whether Shaunak squashed previous ones
15:37:46 <jamiehannaford> how about this one: https://review.openstack.org/#/c/99283/
15:37:51 <mfer> i'm not exactly sure. luckly, gerrit lets us change that in the UI now
15:38:20 <mfer> conceptually I have no issue with it. Just need to do a review of it.
15:38:48 <mfer> Did any of the relevant docs get updated about the autoloader? I'm not sure where it's at in there
15:39:27 <jamiehannaford> which docs do you mean?
15:40:16 <mfer> for example the README.rst file refers to the autoloader
15:40:46 <jamiehannaford> I'll go through again and replace mentions in the docs
15:41:25 <mfer> the only one I'd like to discuss conceptually is https://review.openstack.org/#/c/97482/ which I believe we have as a later topic
15:41:38 <mfer> other than that it's just code reviews on my end
15:41:53 <jamiehannaford> okay - I don't think there's much point reviewing that until URL one is +2ed
15:42:11 <mfer> yeah, that's another one I'm conceptually with but need to code review
15:42:25 <samchoi> so regarding this, are we in agreement that the availability of Composer is assumed?
15:42:26 <mfer> i have a chunk of time today and tomorrow alotted to do code reviews of these things
15:42:40 <jamiehannaford> samchoi yes because there's no other way to install our dependencies
15:42:42 <samchoi> t97482 looks fine to me
15:43:03 <mfer> samchoi composer or another PSR enabled autoloader (like the symfony one). autoloading is shifted as a responsibility to the consumer
15:43:25 <samchoi> ok, I was trying to be cautious even though this review seems quite straightforward
15:43:28 <samchoi> thanks
15:43:38 <jamiehannaford> the other patch is https://review.openstack.org/#/c/99303/
15:43:58 <jamiehannaford> this was discussed very briefly on irc a week or so back
15:44:00 <mfer> I think the question on autoloading is a good one. There are still a lot of apps that don't use composer. For them we should have some documentation on autoloading to point them in the right direction.
15:44:48 <mfer> jamiehannaford i remember that. i'm fine with the idea as I said then. Glad to see you put some code to it. I'll review that when I'm going through all the other stuff
15:45:46 <mfer> samchoi jamiehannaford do you have anything else on these? it sounds like we just need to put time in reviewing code
15:46:11 <samchoi> yes, that sounds about right
15:48:44 <mfer> then I think we can move on
15:48:46 <mfer> #topic How are we going to handle transport state (like base URLs) for services and resource models? (jamiehannaford)
15:48:57 <mfer> jamiehannaford care to start this one off?
15:49:12 <jamiehannaford> based on the mailing list, I like the idea of a stateless transport client
15:49:41 <jamiehannaford> one thing I was wondering about is how we're going to manage service-specific transport state like endpoint URLs and default headers
15:50:13 <jamiehannaford> I don't think a service client or resource model should hold that state, because it's transport-related. But I also agree we shouldn't have it inside the transport client either because it needs to be re-usable
15:50:36 <mfer> I was asking myself the same question. I know how I've done it in the past. Yesterday I started digging into how others do it in both PHP and other languages.
15:51:00 <mfer> I don't think I have an answer yet but it's a question I started asking even before you put this on here
15:51:02 <jamiehannaford> I had an idea
15:51:07 <mfer> or I saw it on here anyway
15:51:34 <mfer> ya
15:51:34 <mfer> '?
15:51:51 <jamiehannaford> I know people aren't comfortable with event subscribers (because it's all a bit abstract with no code), but we could have a subscriber that adds in a base URL/default header array onto a request when its prepared
15:52:36 <jamiehannaford> so it waits until before a request is sent, then modifies the URL with the endpoint domain
15:53:15 <jamiehannaford> that subscriber class would hold the responsibility of adding custom details to requests before they're sent
15:53:19 <mfer> that's similar to what pkgcloud does with the request lib. The default headers are added via events. the url endpoint is handled with a method.
15:53:30 <jamiehannaford> awesome
15:53:36 <jamiehannaford> that's pretty much what I was thinking
15:53:53 <jamiehannaford> you could have another subscriber for controlling authentication
15:54:53 <mfer> i'm not entirely sure of doing it this way mostly because 1) I'd like to do some more reserch and 2) If we don't go with a service and resource model approach I'd like to know what that means. I say #2 because the python SDK moved away from it so I'd like to be smart about our approach and talk with them and others on it.
15:55:14 <jamiehannaford> sure
15:55:29 <jamiehannaford> if we didn't have a service class with affiliated domain models - what would we use instead?
15:55:46 <jamiehannaford> I know pyrax has the concept of managers
15:55:51 <mfer> so, before we start coding to something like this we (and I'm happy to do this but I hope others will as well) should do some legwork.
15:56:08 <mfer> the python SDK is doing something where a class has both state and behavior
15:56:20 <mfer> so, you call a method on a class with state to affect it
15:56:29 <jamiehannaford> hmm
15:56:35 <mfer> so, $object->save() rather than $manager->save($object)
15:56:43 <mfer> that kind of idea anyway
15:57:08 <samchoi> I've been tracking the python sdk's design/progress...I'll reach out to their group as well after I get a better feel for their library
15:57:15 <mfer> yay
15:57:23 <mfer> cross language sharing :)
15:57:34 <jamiehannaford> that's we're doing on the current SDK - you'd have a domain model like $container that contains both state and behaviour
15:58:00 <jamiehannaford> we also have to bear in mind that some things idiomatic in python might not work well in PHP
15:58:54 <samchoi> jamiehannaford: yea will keep that in mind as well. It's been interesting though because I've had to write/edit both styles. The internal SDK I've worked on uses managers.
15:59:26 <samchoi> Honestly, I'm not sure if there's truly a clear benefit to either approach at this point.
15:59:36 <mfer> I've worked on stuff that uses both. Lately I've been following the philosophical debate on how to handle this stuff and the development community is not in agreement
16:00:13 <jamiehannaford> I think we should think about it more over this week
16:00:24 <mfer> how about this, can the three of us take an action to dig into this topic and come back and discuss it when we have more to talk about?
16:00:38 <samchoi> sure, it's already in progress for me
16:01:01 <mfer> If Shanuk or Glen are up for digging into this too I'd love to hear their thoughts
16:01:14 <jamiehannaford> I'll look into the topic of whether a class should both contain state and perform tasks/behaviour
16:01:38 <jamiehannaford> mfer I'll point them to this week's meeting logs so they can weigh in
16:01:44 <mfer> thanks
16:02:16 <mfer> should we move on to the next topic or is there something else here?
16:02:23 <jamiehannaford> is it also worth maybe having a small proof of concept? relating to my idea of the event subscribers
16:02:28 <jamiehannaford> or wait until next week
16:02:33 <jamiehannaford> when we've researched more
16:03:09 <mfer> jamiehannaford if you want to that's fine. I'm familiar with the concept to the point that I don't need an example to understand it.
16:03:20 <mfer> it might be useful for others though
16:03:21 <samchoi> sounds like we're a bit undecided on the resource/manager design vs what the python SDK has done. Fine with moving on
16:03:58 <jamiehannaford> fine with moving on too
16:04:38 <mfer> #topic Do `RemoteObject' and `Object' need to be separate classes? (jamiehannaford)
16:04:46 <mfer> jamiehannaford would you care to take this away?
16:05:18 <jamiehannaford> at the moment I don't really understand the separation - do we need 2 separate classes for 1 API resource?
16:05:51 <mfer> so.... the person who wrote that isn't here. I don't really have an opinion on it.
16:06:03 <mfer> if you want to try to merge them cleanly into one that seems fine to me
16:06:07 <samchoi> mfer: took the words out of my mouth
16:06:20 <jamiehannaford> okay, I'll try and take that on next week
16:06:37 <mfer> that was easy! yay for easy topics
16:06:49 <mfer> is there anything else on this or should we move to open discussion time?
16:07:33 <samchoi> jamiehannaford: mentioned there are several mailing list topics open so seems like a good opportunity to move on
16:07:52 <jamiehannaford> I'm fine with moving on
16:08:22 <mfer> #topic open discussion
16:09:51 <samchoi> so it looks like we briefly discussed the transport layer topic...
16:10:40 <samchoi> leaving us with a discussion on testing approaches (Behat) and philosophies on how users extend the library right? Or was there something else?
16:10:54 <jamiehannaford> I think that's it
16:11:12 <jamiehannaford> so I know folks have concerns with using a BDD tool like behat - shall we go over them?
16:11:39 <jamiehannaford> one of them was "we don't have business analysts, testers or non-coders - so we don't need BDD"
16:11:47 <samchoi> sure, good topic to cover now
16:12:24 <mfer> sure
16:12:26 <jamiehannaford> so, for me, the main point of using a human-readable language was that it improves communication for EVERYONE on the project
16:12:48 <jamiehannaford> it allows to collaborate and really pin down what features are going to look like
16:13:02 <jamiehannaford> so we have a clear idea of what we're coding
16:13:22 <jamiehannaford> there's nothing worse than spending hours coding a new feature only to realize it has nothing in common with what somebody else had in mind
16:13:31 <jamiehannaford> BDD is about improving that communication
16:13:38 <jamiehannaford> and defining features - it's that simple
16:13:57 <jamiehannaford> here's an example I drafted up for a few Swift features - very rudimentary https://gist.github.com/jamiehannaford/73271df790a6cbb5f940
16:14:54 <samchoi> So I think the first thing we should clear up is, are we all in agreement that the php sdk's end users are all developers then?
16:15:14 <jamiehannaford> we can't make that assumption
16:15:25 <jamiehannaford> the honest answer is that we don't know who will use our SDK
16:15:33 <mfer> jamiehannaford who else besides a developer would use the SDK?
16:15:52 <mfer> and why or how?
16:15:58 <samchoi> Well given that this is an sdk...I'm wondering who else would realistically use this. I polled members of other sdk teams as well on this matter.
16:16:05 <mfer> i'm trying to understand where alternatices would come from
16:16:36 <jamiehannaford> "developer" is not a defined thing, it's a label attached to a wide variety of people with different skillsets
16:16:53 <jamiehannaford> but that's not really the point
16:17:02 <jamiehannaford> BDD is about communication on our team
16:17:12 <jamiehannaford> and understanding how end-users (whoever they are) will use our SDK
16:17:41 <mfer> BDD is also about process and having a team of people use that process.
16:17:58 <jamiehannaford> no, BDD is about improving communication
16:17:59 <mfer> if a team of contributors isn't really interested in that process it's going to have a hard time happening
16:18:23 <jamiehannaford> what's more important than having good communication on a development team?
16:18:32 <jamiehannaford> to give you an example:
16:18:42 <jamiehannaford> the RemoteObject and Object classes
16:18:51 <jamiehannaford> I still have no idea what they really do
16:19:21 <jamiehannaford> there's a communication gap there - and any time I spend trying to understand, refactor or undo that miscommunication is time we can better spend
16:19:53 <jamiehannaford> all I'm saying is that it'd be really cool to have a way to define features consistently and easily
16:20:05 <mfer> So, when you read the docs at https://github.com/stackforge/openstack-sdk-php/blob/master/src/OpenStack/ObjectStore/v1/Resource/Object.php#L23 you didn't know what the class did?
16:20:37 <samchoi> I would also mention that from the polling I've done, similar contributors don't seem interested in using a BDD framework for an SDK. After hearing back from a number of guys working on other OpenStack SDKs, I was surprised to see that none of them thought using a BDD framework made sense for an OpenStack SDK
16:20:59 <jamiehannaford> I didn't understand the reason for separating a "remote object" from an "object" - why that decision was ever made
16:21:17 <mfer> jamiehannaford ah. i get that question.
16:22:09 <jamiehannaford> all behat is doing is opening up that decision making process (what goes into a feature) so we don't waste time
16:22:12 <mfer> jamiehannaford so, the openstack community puts a lot of process in place. most of it so big giant companies can play nicely together. putting this in place would be additional process that other projects in openstack (or PHP in general) aren't doing. That means the people involved need to be sold on doing things this way.
16:22:28 <mfer> it's a process (it may be a communication process) but it's still process
16:22:34 <jamiehannaford> two things:
16:23:14 <jamiehannaford> 1. I don't understand the "well other people aren't doing it" argument - it's cropped up a lot (and even figured in the stateless transport client debate). We should decide based on the merits of something, not by following others
16:23:35 <jamiehannaford> 2. there are projects inside Rackspace that have been extremely successfuly using BDD/Cucumber
16:23:58 <mfer> jamiehannaford those are good things to bring up. let's talk about them
16:24:52 <samchoi> jamiehannaford: to be clear, this isn't about other people using it. Based on the info I've received, nobody else supports using a BDD framework for an OpenStack SDK at the moment. Going back to Matt's point, there would be no support to using this process were it to be put in place.
16:25:16 <jamiehannaford> samchoi what do you mean by "no support to using this process"?
16:25:22 <samchoi> I had some extended conversations with contributors to other SDKs and they made a decision not to use a BDD framework
16:25:28 <jamiehannaford> we'd write the files and run a script
16:25:37 <mfer> for #1 I'm not opposed to doing different than popular things on the technology front. When it comes to project process I'm a little more skeptical. If we introduce something really different from the other projects we should be excited about it. I'm just not finding that in myself or the others I've talked with. Putting process in place for contributors (and volunteers in some cases) in addition to the hoops we already have
16:25:37 <mfer> needs some excitement we can share and get behind
16:25:49 <jamiehannaford> samchoi could you share those conversations on the mailing list? I'm genuinely interested in the counter-arguments
16:26:05 <samchoi> I can share some of the insights right now actually
16:26:10 <samchoi> since the mailing list is quite cluttered
16:26:32 <samchoi> they come from a wide variety of backgrounds so I expected more variance
16:26:33 <mfer> and to #2 I'm not sure how those projects are run inside rackspace. there are projects inside HP that could use BDD and I imagine in some groups there are. But, this is a different sort of project. Communication and process are context sensetitive to the people and the projects.
16:26:49 * mfer is all ears to hear samchoi
16:27:03 <samchoi> So I'm going to roughly paraphrase what I've noted down
16:27:08 <samchoi> since I didn't ask to directly quote people
16:27:15 <jamiehannaford> mfer but that's the thing - they're not different whatsoever. Better communication is useful for all projects
16:27:15 <samchoi> but I'm staying true to their statements
16:27:20 <samchoi> - It appears to be overkill for an "...SDK when your 'business requirements' are to perform an HTTP GET"
16:27:32 <samchoi> (mentioned by several devs)
16:27:51 <samchoi> - if 90% or more of the people on the team are coders.. 	then why bother writingthings in english.. then taking the time to make a translation layer or using another tool in the chain to generate the code
16:28:03 <samchoi> (indicating little support for a BDD framework)
16:28:31 <samchoi> - BDD in itself is not bad, but BDD and "human readable tests" are two different things. Big fan of the former, not so much the latter
16:28:54 <samchoi> again, these are their statements, possibly shortened, not mine
16:28:57 <jamiehannaford> BDD is all about human readable tests - it's a communication tool, that is its point
16:29:05 <jamiehannaford> I can respond to these on the mailing list
16:29:09 <jamiehannaford> I think we're running out of time
16:29:30 <mfer> jamiehannaford good catch on the time
16:29:34 <jamiehannaford> were those all the points, sam?
16:29:55 <mfer> jamiehannaford I'll ask one thing. respond in a way that can get people excited and around it. this is about moving people more than the architecture issues.
16:29:58 <samchoi> there were a few more I believe, but it was quite clear that they did not support using a bdd frmaework
16:30:02 <mfer> that will help you sell it
16:30:20 <mfer> ok, we have to run... time for the next meeting.
16:30:21 <tjones> hi folks you about done?  getting ready to start a meeting here now
16:30:23 <mfer> #endmeeting