Re: [openstack-dev] [openstack-sdk-php] Review of face to face meeting on direction for SDK.
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 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 i
Re: [openstack-dev] [openstack-sdk-php] Review of face to face meeting on direction for SDK.
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
mailto: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
