Shaunak, I think it's safe to say I agree with all of your points. Thanks for responding so quickly.
On Thu, Jul 31, 2014 at 7:01 PM, Shaunak Kashyap < shaunak.kash...@rackspace.com> wrote: > Thanks for compiling this, Matt. I think you captured all the major > points here; I just have three additions/changes: > > class RackspaceObject extends Object {} > > > 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. > > 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? > > The idea is to use inheritance where needed. This style is quite common > in PHP. > > > 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. > > Common properties could be protected while uncommon ones, or those we > aren't sure of would be private. > > > Based on the example we tried out in http://3v4l.org/ (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. > > Thanks, > > Shaunak > > On Jul 31, 2014, at 6:40 PM, Matthew Farina <m...@mattfarina.com> wrote: > > 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. > > In attendance were, > - Glen Campbell, Rackspace > - Shaunak Kashyap, Rackspace > - Sam Choi, HP > - Matt Farina, HP > > I want to thank everyone who came. This was a productive and good > meeting. > > 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. > > In addition to the process we discussed reasons a patchset in review > would receive a -1 right away. These include: > - Duplicate effort > - Doesn't meet the coding standard > - The tests fail > - Counter to previously documented decision > - A work in progress (until we come up with a better way to handle that) > - Big feature not tied to a blueprint > > We discussed the target audiences for PHP SDK work. The customers are, > in priority order: > 1. SDK Consumer > 2. Builders of the SDK > 3. Extenders of the SDK > > Note, #2 and #3 are very close to each other and a distance behind #1. > > 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: > - Symfony > - Laravel > - Zend Framework > - Wordpress > - Drupal > - Joomla > - Spagetti Code > > We also noted the difference between Products (that will be shipped) and > services that use the code. > > 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). > > There were several topics where we came to technical direction. > > The directory structure will be the following style... > > identity/v2/ > identity/v3/ > objectStore/v1/ > compute/v2/ > compute/v3/ > > 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. > > When it comes to extending classes for functionality we came to a > conclusion to use the style... > > class RackspaceObject extends Object {} > > 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. > > An example of the scoping and using it in the inheritance model can be > seen at http://3v4l.org/peMiO. > > At the top an OpenStack general object could be used to make the > experience easier. For example... > > $service = $openstack->service(...); > > 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. > > The end user style discussed was based on 3 differing options. The > options discussed were.. > > 1. An ORM style. For example, > > $object = $objectStore->getContainer('foo')->getObject('bar'); > > 2. Working with objects directly. For example, > > $object = new Obejct(); > $object->setRegion('region'); > $object->setContainer('foo'); > ... (more sets) > $object->load(); > > 3. A DSL Style. For example, > > $object = $objectStorage->get(...) > > Here ... is an array defining what to get. > > The direction that clearly came forward was the #1 option. It was the > one everyone tended towards. > > 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. > > 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. > > Action Items > ------------ > - (Matt) Document the OpenStack/Gerrit workflow. > - Find 3rd party arbitrators. > - BDD or not to BDD decision. > - (Glen) Discussion into successes and failures of using interfaces. > - Document common properties to consider for protected scoping rather than > private scoping. > > Decisions > --------- > - For disagreements we agree to use an agreed to arbitrator. > - Public scoping of methods is for those defined in interfaces. > - Example/test of how an end user should do something should come before > functionality. > - Use a session to keep the identity around and useful. Re-authenticating > from an expired token or something along those lines should be automatic. > - We need to document everything. This will be useful for later reference. > There needs to be less tribal knowledge. > > > If I missed or was in error of something please let me know. I think I > captured the big items here. > > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev