<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Shaunak</span>, I think it's safe to say I agree with all of your points. Thanks for responding so quickly.</div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Thu, Jul 31, 2014 at 7:01 PM, Shaunak Kashyap <span dir="ltr"><<a href="mailto:shaunak.kashyap@rackspace.com" target="_blank">shaunak.kashyap@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div style="word-wrap:break-word">
Thanks for compiling this, Matt. I think you captured all the major points here; I just have three additions/changes:
<div><br>
</div>
<div>
<blockquote type="cite">
<div dir="ltr">    class RackspaceObject extends Object {}</div>
</blockquote>
<div>
<div dir="ltr"><br>
</div>
</div>
<div dir="ltr">I know this is the exact sample code we put up on the whiteboard and I know we totally didn’t discuss namespaces at all at the time.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Looking at this snippet now, though, I’m wondering if using namespaces here would be better so instead of RackspaceObject, the class name would be just Object but in the Rackspace namespace. Presumably the name of the class being extended would
 also be Object (as is the case in the sample code) but that class would be part of the OpenStack (or Core or something) namespace. Thoughts?</div><div class="">
<div dir="ltr"><br>
</div>
<div dir="ltr">
<blockquote type="cite">
<div dir="ltr">The idea is to use inheritance where needed. This style is quite common in PHP. </div>
</blockquote>
<br>
</div>
</div><div dir="ltr">I’ll add here something I mentioned during our meeting: We would favor inheritance for scenarios such as extending an OpenStack-oriented class to a Rackspace-oriented class. We would favor composition and dependency injection for cross-cutting
 concerns such as logging.</div><div class="">
<div dir="ltr"><br>
</div>
<div dir="ltr">
<blockquote type="cite">
<div dir="ltr">Common properties could be protected while uncommon ones, or those we aren't sure of would be private.</div>
</blockquote>
<br>
</div>
</div><div dir="ltr">Based on the example we tried out in <a href="http://3v4l.org/" target="_blank">http://3v4l.org/</a> (thanks for pointing us to this site, btw), I thought we were tending towards this convention: all properties would be private, their accessors (getters/setters)
 would either be public or protected; derived classes would access these properties via these accessor methods, using “parent::somePropertyAccessorMethod()” if necessary.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Thanks,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Shaunak</div><div><div class="h5">
<div dir="ltr"><br>
</div>
<div>
<div>On Jul 31, 2014, at 6:40 PM, Matthew Farina <<a href="mailto:matt@mattfarina.com" target="_blank">matt@mattfarina.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>We just completed a meeting on the OpenStack SDK for PHP and this email attempts to sum up the discussion and action items to come from the meeting. This was a face to face meeting that included discussions of processes and architecture.</div>

<div><br>
</div>
<div>In attendance were,</div>
<div>- Glen Campbell, Rackspace</div>
<div>- Shaunak Kashyap, Rackspace</div>
<div>- Sam Choi, HP</div>
<div>- Matt Farina, HP</div>
<div><br>
</div>
<div>I want to thank everyone who came. This was a productive and good meeting.</div>
<div><br>
</div>
<div>The conversation opened with a discussion of process. We discussed the Gerrit and review process used by the OpenStack community and how Gerrit was configured for the PHP SDK codebase. Matt took an action item to document the process.</div>

<div><br>
</div>
<div>In addition to the process we discussed reasons a patchset in review would receive a -1 right away. These include:</div>
<div>- Duplicate effort</div>
<div>- Doesn't meet the coding standard</div>
<div>- The tests fail</div>
<div>- Counter to previously documented decision</div>
<div>- A work in progress (until we come up with a better way to handle that)</div>
<div>- Big feature not tied to a blueprint</div>
<div><br>
</div>
<div>We discussed the target audiences for PHP SDK work. The customers are, in priority order:</div>
<div>1. SDK Consumer</div>
<div>2. Builders of the SDK</div>
<div>3. Extenders of the SDK</div>
<div><br>
</div>
<div>Note, #2 and #3 are very close to each other and a distance behind #1.</div>
<div><br>
</div>
<div>When we looked at the SDK Consumer we documented we noted a number of projects that should be able to use the SDK easily. These include:</div>
<div>- Symfony</div>
<div>- Laravel</div>
<div>- Zend Framework</div>
<div>- Wordpress</div>
<div>- Drupal</div>
<div>- Joomla</div>
<div>- Spagetti Code</div>
<div><br>
</div>
<div>We also noted the difference between Products (that will be shipped) and services that use the code.</div>
<div><br>
</div>
<div>As part of the process we looked at breaking ties. Since the project is being entirely worked on by two companies it would be nice to have 3rd parties as a tie breaker. We discussed using the community. We decided to use a 3rd party agreed to arbitrator
 who is willing and we agree to. For example, someone like Larry Garfield (who we have not contacted yet but is an example of this type of person).</div>
<div><br>
</div>
<div>There were several topics where we came to technical direction.</div>
<div><br>
</div>
<div>The directory structure will be the following style...</div>
<div><br>
</div>
<div>    identity/v2/</div>
<div>    identity/v3/</div>
<div>    objectStore/v1/</div>
<div>    compute/v2/</div>
<div>    compute/v3/</div>
<div><br>
</div>
<div>A service for a version will be the point of reference. In an attempt to make extending or replacing the code for a service a viable option we're looking into interfaces at the level of a service with additional interface definition at the level of a service
 version. For example, compute could have an interface with a reboot method. Then compute v3 could have an interface that extends the compute interface and adds a compute v3 method/feature. Code consuming the these can check against the interfaces. Glen took
 an action item to arrange feedback on the interface style from some who have worked with this in the past for other SDKs.</div>
<div><br>
</div>
<div>When it comes to extending classes for functionality we came to a conclusion to use the style...</div>
<div><br>
</div>
<div>    class RackspaceObject extends Object {}</div>
<div><br>
</div>
<div>The idea is to use inheritance where needed. This style is quite common in PHP. Scoping (public/protected/private) for methods and properties was discussed. Common properties could be protected while uncommon ones, or those we aren't sure of would be private.
 The only public methods would be those defined by the interface.</div>
<div><br>
</div>
<div>An example of the scoping and using it in the inheritance model can be seen at
<a href="http://3v4l.org/peMiO" target="_blank">http://3v4l.org/peMiO</a>.</div>
<div><br>
</div>
<div>At the top an OpenStack general object could be used to make the experience easier. For example...</div>
<div><br>
</div>
<div>  $service = $openstack->service(...);</div>
<div><br>
</div>
<div>The ... here is an array with a well documented structure for service discovery from the service catalog. A session should be used to handle the identity and make it easy for users.</div>
<div><br>
</div>
<div>The end user style discussed was based on 3 differing options. The options discussed were..</div>
<div><br>
</div>
<div>1. An ORM style. For example,</div>
<div><br>
</div>
<div>    $object = $objectStore->getContainer('foo')->getObject('bar');</div>
<div><br>
</div>
<div>2. Working with objects directly. For example,</div>
<div><br>
</div>
<div>    $object = new Obejct();</div>
<div>    $object->setRegion('region');</div>
<div>    $object->setContainer('foo');</div>
<div>    ... (more sets)</div>
<div>    $object->load();</div>
<div> </div>
<div>3. A DSL Style. For example,</div>
<div><br>
</div>
<div>    $object = $objectStorage->get(...)</div>
<div><br>
</div>
<div>Here ... is an array defining what to get.</div>
<div><br>
</div>
<div>The direction that clearly came forward was the #1 option. It was the one everyone tended towards.</div>
<div><br>
</div>
<div>We noted that we might want to add ->execute() to the end but that's an optimization we can look at in the future. It could optimize to minimize http requests. </div>
<div><br>
</div>
<div>To make it easier to understand end users, we want to have examples/tests of real world code developers consuming the code could use. This will help define APIs and real world needs. This should come before the implementing code or along with it.</div>

<div><br>
</div>
<div>Action Items</div>
<div>------------</div>
<div>- (Matt) Document the OpenStack/Gerrit workflow.</div>
<div>- Find 3rd party arbitrators.</div>
<div>- BDD or not to BDD decision.</div>
<div>- (Glen) Discussion into successes and failures of using interfaces.</div>
<div>- Document common properties to consider for protected scoping rather than private scoping.</div>
<div><br>
</div>
<div>Decisions</div>
<div>---------</div>
<div>- For disagreements we agree to use an agreed to arbitrator.</div>
<div>- Public scoping of methods is for those defined in interfaces.</div>
<div>- Example/test of how an end user should do something should come before functionality.</div>
<div>- Use a session to keep the identity around and useful. Re-authenticating from an expired token or something along those lines should be automatic.</div>
<div>- We need to document everything. This will be useful for later reference. There needs to be less tribal knowledge.</div>
<div><br>
</div>
<div><br>
</div>
<div>If I missed or was in error of something please let me know. I think I captured the big items here.</div>
</div>
</blockquote>
</div>
<br>
</div></div></div>
</div>

</blockquote></div><br></div>