<html>
<head>
<!-- Template generated by Exclaimer Mail Disclaimers on 01:47:10 Friday, 6 June 2014 -->
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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>
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<p class="ae431132-9d17-4a38-b6b5-634369783623"></p>
<div id="bloop_customfont">
<blockquote type="cite" class="clean_bq">
<div dir="ltr">
<div class="gmail_extra">Whether the same one is used for each service or a new one is used for each service doesn't matter.</div>
</div>
</blockquote>
</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">Yes, it does matter IMO - and here are the reasons why:</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">1. By sharing a global transport object you’re introducing the risk of side effects. A transport object contains state that can be modified by its service object. Somewhere along the line, a Swift service could introduce a state modification
that’s completely incompatible with a Nova service. What’s worse is that it will be a nightmare to debug - you’d have to trawl the entire service to see points where it interacts with the transport client. This is why people don’t use singletons - it’s incredibly
risky and hard to debug. Object instantiations, on the other hand, are cheap and they offer protection through isolation.</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont"> 2. Certain services rely on custom transport configurations. Each transport client has a base URL that is used for issuing HTTP requests - every time you execute a request, you’re effectively adding relevant paths for that API operation.
A Swift service will have different URL endpoints from a Nova one - so there’s no point sharing. Another example is custom headers. Marconi requests custom headers to be sent, as does Glance. You save these as default headers on the transport client, that
are sent for all requests that the service executes. These custom headers are not applicable to any other service except Marconi/Glance.</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">In the use-cases you mentioned, you’d easily handle that. You’d pass in proxy settings through the OpenStack entry point (like you do with your username and password), which would then percolate down into the transport clients as
they’re created. These settings would be injected into each transport client. So if you require a different set-up for public clouds - that’s fine - you define different settings and fire up another $openstack object. </div>
<div id="bloop_customfont"><b><br>
</b></div>
<div id="bloop_customfont"><b>-OR-</b> you could define different transport settings for different services - by passing them into the $openstack->get(‘compute’, [‘custom_settings’ => true]); call. This is great because it gives users the ability to apply custom
transport options to certain services. So if I want to interact with a private Compute instance, I’d pass in a custom transport configuration for that service; if I wanted to use a proxy with my Swift service, I can pass details into that service when creating
it. You can only do this (provide custom transport settings for 1 service) if each transport client is isolated, i.e. if there’s a 1-to-1 relationship between service and transport client. If you have a global one, you couldn’t introduce custom settings per
service because it’d affect ALL others, which is a bad user experience.</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">Jamie</div>
<br>
<p style="color:#000;">On June 5, 2014 at 6:33:34 PM, Matthew Farina (<a href="mailto:matt@mattfarina.com">matt@mattfarina.com</a>) wrote:</p>
<blockquote type="cite" class="clean_bq"><span>
<div>
<div></div>
<div>
<title></title>
<div dir="ltr">
<div><br class="">
> My opinion is that we create a <b>new</b> transport client instance for every service client, not re-use existing instances. What’s your take on this?</div>
<div><br>
</div>
<div class="gmail_extra">I'm not in agreement and here is why (with a use case).</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">A transport client is concerned with transporting only. Whether the same one is used for each service or a new one is used for each service doesn't matter.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">An example of using two transport clients would be a case where an application communicates with two different OpenStack clouds. One is a public cloud and the application communicates through a proxy. A transport client would know how
to talk through the proxy to the public cloud. A second OpenStack cloud is a private cloud that is on the same company network. A second transport client would know how to talk to that without communicating through the proxy.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">The service clients communicating with each cloud would use the appropriate transport client.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">The mapping of transport client to service client doesn't need to be 1:1 if they operate in different spaces. Only having instances of a transport client as needed decreases the use of resources or the time needed to manage those.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">If a transport client is only concerned with transporting than what is the need to have more than one per case to transport?<br>
<br>
- Matt<br>
<br>
<div class="gmail_quote">On Thu, Jun 5, 2014 at 12:09 PM, Jamie Hannaford <span dir="ltr">
<<a href="mailto:jamie.hannaford@rackspace.com" target="_blank">jamie.hannaford@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>I completely agree with you regarding separation of concerns. </div>
<div><br>
</div>
<div>I also agree with your definitions: a transport client is for managing HTTP transactions, a service client contains all the domain logic for an API service (Swift, Nova, etc.). A service knows nothing about HTTP, a transport client knows nothing about
Swift. A transport client is injected into the service client, satisfying the type hint. So any transport client implementing our interface is fine.</div>
<div><br>
</div>
<div>Up to this point I’m in 100% agreement. The area which I think I misunderstood was the
<i>creation process</i> of service clients. My take was that you were advocating a shared transport client instance - i.e. a transport client instantiated once, and re-used for every service client. If we did that, there would be global state. </div>
<div><br>
</div>
<div>My opinion is that we create a <b>new</b> transport client instance for every service client, not re-use existing instances. What’s your take on this?</div>
<div><br>
</div>
<div>Jamie</div>
<div>
<div class="h5"><br>
<p style="color:rgb(0,0,0)">On June 5, 2014 at 5:17:57 PM, Matthew Farina (<a href="mailto:matt@mattfarina.com" target="_blank">matt@mattfarina.com</a>) wrote:</p>
<blockquote type="cite">
<div>
<div><span>We've started to talk about the interactions between transport<br>
clients, service clients, and state. I've noticed we're not on the<br>
same page so I wanted to start a dialog. Here's my starting point...<br>
<br>
A Transport Client is about transporting data. It sends and receives data.<br>
<br>
A Service Client handles the interactions with a service (e.g., swift,<br>
nova, keystone).<br>
<br>
A Service Client uses a Transport Client when it needs to transport<br>
data to and from a service.<br>
<br>
When it comes to state, a Transport Client knows about transporting<br>
things. That means it knows things like if there is a proxy and how to<br>
work with it. A Service Client knows about a service which includes<br>
and state for that service.<br>
<br>
In the realm of separation of concerns, a Service Client doesn't know<br>
about transport state and a Transport Client doesn't know about<br>
service state. They are separate.<br>
<br>
A Service Client doesn't care what Transport Client is used as long as<br>
the API (interface) is compliant. A Transport Client doesn't care what<br>
code calls it as long as it uses the public API defined by an<br>
interface.<br>
<br>
This is my take. If someone has a different take please share it with<br>
the reasoning.<br>
<br>
- Matt<br>
</span></div>
</div>
</blockquote>
</div>
</div>
<p> </p>
<table border="0" cellpadding="0" width="504">
<tbody>
<tr>
<td style="width:270px"><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" width="159" height="17"></td>
</tr>
<tr>
<td colspan="2"><img alt="LINE" width="504" height="4"></td>
</tr>
<tr>
<td>
<table>
<tbody>
<tr>
<td><span style="font-family:Verdana;font-size:x-small">Tel:</span></td>
<td><span style="font-family:Verdana;font-size:x-small"><a href="tel:%2B41434303908" value="+41434303908" target="_blank">+41434303908</a></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"><a href="tel:%2B41791009767" value="+41791009767" target="_blank">+41791009767</a></span></td>
</tr>
</tbody>
</table>
</td>
<td><img alt="Rackspace" width="280" height="60"></td>
</tr>
<tr>
<td colspan="2"><img width="504" height="3"></td>
</tr>
</tbody>
</table>
<p> </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 <a href="http://www.rackspace.co.uk/legal/swiss-privacy-policy" target="_blank">
www.rackspace.co.uk/legal/swiss-privacy-policy</a><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 <a href="http://www.rackspace.com.au/company/legal-privacy-statement.php" target="_blank">
www.rackspace.com.au/company/legal-privacy-statement.php</a><br>
-<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 <a href="http://www.rackspace.com/information/legal/privacystatement" target="_blank">
www.rackspace.com/information/legal/privacystatement</a></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 <a href="http://www.rackspace.co.uk/legal/privacy-policy" target="_blank">
www.rackspace.co.uk/legal/privacy-policy</a></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
<a href="http://www.rackspace.nl/juridisch/privacy-policy" target="_blank">www.rackspace.nl/juridisch/privacy-policy</a></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
<a href="http://www.rackspace.com.hk/company/legal-privacy-statement.php" target="_blank">
www.rackspace.com.hk/company/legal-privacy-statement.php</a></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
<a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a> and delete the original message. Your cooperation is appreciated.</span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</span></blockquote>
<p></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:imagea6fd99.JPG@c24b2015.49b9ef2f" width="159" height="17"></td>
</tr>
<tr class="LEFT_ALIGNED">
<td colspan="2"><img alt="LINE" src="cid:image7b6ad3.JPG@cb19cfe4.4c9e9666" width="504" height="4"></td>
</tr>
<tr>
<td class="CONTACTINFO"><span style="font-family:Calibri; ">
<table class="ae431132-9d17-4a38-b6b5-634369783623Table">
<tbody>
<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>
</tbody>
</table>
</span></td>
<td class="RIGHT_ALIGNED"><img alt="Rackspace" src="cid:image738067.JPG@cb9c11ab.4db21693" width="280" height="60"></td>
</tr>
<tr class="LEFT_ALIGNED">
<td class="CONTACTINFO" colspan="2"><img src="cid:image2388db.JPG@3059fceb.4b86fa89" 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>