<HTML>
<HEAD><!-- Template generated by Exclaimer Mail Disclaimers on 06:09:13 Wednesday, 30 April 2014 -->
<STYLE type=text/css>P.ae431132-9d17-4a38-b6b5-634369783623 {
MARGIN: 0cm 0cm 0pt
}
LI.ae431132-9d17-4a38-b6b5-634369783623 {
MARGIN: 0cm 0cm 0pt
}
DIV.ae431132-9d17-4a38-b6b5-634369783623 {
MARGIN: 0cm 0cm 0pt
}
TABLE.ae431132-9d17-4a38-b6b5-634369783623Table {
MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
page: Section1
}
</STYLE>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</HEAD>
<BODY style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<P class=ae431132-9d17-4a38-b6b5-634369783623>
<div>Hey everyone,</div>
<div><br />
</div>
<div>So I've been working on the transport layer today and wanted to run some thing past everyone to make sure we're all on the same page. There's no new major new work: just tweeking some existing stuff and moving functionality into new files where I thought
it would make things clearer.</div>
<div><br />
</div>
<div><b>1. Minor updates `ClientInterface`</b></div>
<div><br />
</div>
<div>I agree with Matt: we need to keep this interface as simple as possible for new client classes to implement. There's two discrete pieces of functionality the interface should care about: requests and configuration. Here's an outline of what I thought might
work:</div>
<div><br />
</div>
<div><a href="https://gist.github.com/jamiehannaford/01bbf366f5f3da07bbcd">https://gist.github.com/jamiehannaford/01bbf366f5f3da07bbcd</a></div>
<div><br />
</div>
<div>I tried to keep things as simple as possible - can people lend me their thoughts on it?</div>
<div><br />
</div>
<div>One of the main differences with the current version is that it separates out the process of
<i>creating</i> a request from <i>sending</i> it. Right now we do it in one method, which is disadvantageous for two reasons:</div>
<div><br />
</div>
<div>1. It prevents users from modifying the Request object before sending it. Matt raised a very good point that you can pass in extra headers, etc. into the signature itself - but what I'm talking about is things like event subscribers. In the lifecycle of
a cURL transaction (a Request being created, prepared, and sent; a response being parsed, etc.) different events are emitted. These events are incredibly useful and empowering for end-users because they enable people to add in their own custom logic to processes
which are usually unavailable (unless you actually extend the SDK code). By having a "createRequest" method that actually
<i>returns </i>a Request rather than just sending it, we're allowing users to add their own subscribers. Here are a few use-cases: a user might want to add a subscriber which logs everything for that 1 request; a user might want to use a subscriber to handle
exceptions differently for that 1 request; a user might want to retry the Request if a particular status code is returned, etc.</div>
<div><br />
</div>
<div>2. Most common HTTP frameworks, like Guzzle and ZF2, use these two methods ("createRequest" and "send"). It makes sense to stick with convention so end-users and contributors are not confused.</div>
<div><br />
</div>
<div><br />
</div>
<div><b>2. Moving Guzzle stuff to a sub-directory</b></div>
<div><br />
</div>
<div>Right now we're using Guzzle by default, but we also want to support the ability for users to inject their own HTTP client in. So to make this clearer, I've moved Guzzle-specific files to their own "Guzzle" sub-directory (under the OpenStack\Common\Transport\Guzzle
namespace). I've also changed the "GuzzleClient" classname to "GuzzleAdapter" because it's actually
<i>adapting </i>an existing client, not <i>serving </i>as one. All it's doing is wrapping Guzzle and implementing our standard interface - so I wanted to make that clearer and avoid confusion.</div>
<div><br />
</div>
<div><br />
</div>
<div><b>3. HTTP exceptions</b></div>
<div><br />
</div>
<div>I also discovered a really cool way to handle exceptions. Right now, we're throwing exceptions in the adapter - which adds a lot of exception-specific logic to a base class. So instead, I copied all of this existing logic to a new "RequestException" class.
All the GuzzleClient/GuzzleAdapter needs to do is call RequestException::create($request, $response) and all of the logic for finding the right class for the right HTTP status code is determined inside RequestException like this:</div>
<div><br />
</div>
<div><a href="https://gist.github.com/jamiehannaford/0a085d4b1507308b0190">https://gist.github.com/jamiehannaford/0a085d4b1507308b0190</a></div>
<div><br />
</div>
<div>Another thing I wanted to do is make it easier for devs to debug the problem once an exception is thrown - so I made the Request and Response objects (for a failed request) available in the exception. So instead of printing out a generic message, we also
allow them the ability to retrieve the offending request/response with $e->getRequest() and $e->getResponse()</div>
<div><br />
</div>
<div>---</div>
<div><br />
</div>
<div>That's about it, basically :)</div>
<div><br />
</div>
<div>Does anybody have any questions or concerns with any of this?</div>
<div><br />
</div>
<div>Jamie</div>
</P>
<P class=ae431132-9d17-4a38-b6b5-634369783623> </P>
<P class=ae431132-9d17-4a38-b6b5-634369783623>
<TABLE border=0 cellPadding=0 width=504>
<TBODY>
<TR>
<TD style="WIDTH: 270px" class=LEFT_ALIGNED><span style='font-family:Verdana; font-size:small; '>Jamie Hannaford</span><BR /><span style='font-family:Verdana; font-size:x-small; '>Software Developer III - CH</span></TD>
<TD style="WIDTH: 281px"><IMG alt="experience Fanatical Support" align=right src="cid:image1133a4.JPG@de848d9a.4aa0f42e" width=159 height=17 /></TD></TR>
<TR class=LEFT_ALIGNED>
<TD colSpan=2><IMG alt=LINE src="cid:image52edff.JPG@f5bd7a9a.46a7ef1b" width=504 height=4 /></TD></TR>
<TR>
<TD class=CONTACTINFO><span style='font-family:Calibri; '><table class=ae431132-9d17-4a38-b6b5-634369783623Table><tr><td><span style='font-family:Verdana; font-size:x-small; '>Tel: </span></td><td><span style='font-family:Verdana; font-size:x-small; '>+41434303908</span></td></tr><tr><td><span style='font-family:Verdana; font-size:x-small; '>Mob: </span></td><td><span style='font-family:Verdana; font-size:x-small; '>+41791009767</span></td></tr></table></span></TD>
<TD class=RIGHT_ALIGNED><IMG alt=Rackspace src="cid:image2b0bf6.JPG@bfaaa5fe.40a0b770" width=280 height=60 /></TD></TR>
<TR class=LEFT_ALIGNED>
<TD class=CONTACTINFO colSpan=2><IMG src="cid:imagec2ddd4.JPG@94810b09.47a963f5" width=504 height=3 /></TD></TR></TBODY></TABLE></P>
<P class=ae431132-9d17-4a38-b6b5-634369783623> </P>
<P class=ae431132-9d17-4a38-b6b5-634369783623></P><span style="font-size: 11px;">Rackspace International GmbH a company registered in the Canton of Zurich, Switzerland (company identification number CH-020.4.047.077-1) whose registered office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. Rackspace International GmbH privacy policy can be viewed at www.rackspace.co.uk/legal/swiss-privacy-policy<br>-<br>Rackspace Hosting Australia PTY LTD a company registered in the state of Victoria, Australia (company registered number ACN 153 275 524) whose registered office is at Suite 3, Level 7, 210 George Street, Sydney, NSW 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be viewed at www.rackspace.com.au/company/legal-privacy-statement.php<br>-<span style="font-size: 11px;"></span><br>Rackspace US, Inc, 5000 Walzem Road, San Antonio, Texas 78218, United States of America</span><br><span style="font-size: 11px;">Rackspace US, Inc privacy policy can be viewed at www.rackspace.com/information/legal/privacystatement</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ.</span><br><span style="font-size: 11px;">Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">Rackspace Benelux B.V. is a company registered in the Netherlands (company KvK nummer 34276327) whose registered office is at Teleportboulevard 110, 1043 EJ Amsterdam.</span><br><span style="font-size: 11px;">Rackspace Benelux B.V privacy policy can be viewed at www.rackspace.nl/juridisch/privacy-policy</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">Rackspace Asia Limited is a company registered in Hong Kong (Company no: 1211294) whose registered office is at 9/F, Cambridge House, Taikoo Place, 979 King's Road, Quarry Bay, Hong Kong.</span><br><span style="font-size: 11px;">Rackspace Asia Limited privacy policy can be viewed at www.rackspace.com.hk/company/legal-privacy-statement.php</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">This e-mail message (including any attachments or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse@rackspace.com and delete the original message. Your cooperation is appreciated.</span></BODY>
</HTML>