Open Stack

I completely agree with you regarding separation of concerns.

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.

Up to this point I’m in 100% agreement. The area which I think I misunderstood was the creation process 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.

My opinion is that we create a new transport client instance for every service client, not re-use existing instances. What’s your take on this?

Jamie


On June 5, 2014 at 5:17:57 PM, Matthew Farina (matt at mattfarina.com<mailto:matt at mattfarina.com>) wrote:

We've started to talk about the interactions between transport
clients, service clients, and state. I've noticed we're not on the
same page so I wanted to start a dialog. Here's my starting point...

A Transport Client is about transporting data. It sends and receives data.

A Service Client handles the interactions with a service (e.g., swift,
nova, keystone).

A Service Client uses a Transport Client when it needs to transport
data to and from a service.

When it comes to state, a Transport Client knows about transporting
things. That means it knows things like if there is a proxy and how to
work with it. A Service Client knows about a service which includes
and state for that service.

In the realm of separation of concerns, a Service Client doesn't know
about transport state and a Transport Client doesn't know about
service state. They are separate.

A Service Client doesn't care what Transport Client is used as long as
the API (interface) is compliant. A Transport Client doesn't care what
code calls it as long as it uses the public API defined by an
interface.

This is my take. If someone has a different take please share it with
the reasoning.

- Matt



Jamie Hannaford
Software Developer III - CH     [experience Fanatical Support]

Tel:    +41434303908
Mob:    +41791009767
        [Rackspace]



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
-
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
-
Rackspace US, Inc, 5000 Walzem Road, San Antonio, Texas 78218, United States of America
Rackspace US, Inc privacy policy can be viewed at www.rackspace.com/information/legal/privacystatement
-
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.
Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy
-
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.
Rackspace Benelux B.V privacy policy can be viewed at www.rackspace.nl/juridisch/privacy-policy
-
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.
Rackspace Asia Limited privacy policy can be viewed at www.rackspace.com.hk/company/legal-privacy-statement.php
-
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 at rackspace.com and delete the original message. Your cooperation is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140605/1241fb76/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagee05d74.JPG
Type: image/jpeg
Size: 3124 bytes
Desc: imagee05d74.JPG
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140605/1241fb76/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagef322c9.JPG
Type: image/jpeg
Size: 990 bytes
Desc: imagef322c9.JPG
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140605/1241fb76/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image80b5f0.JPG
Type: image/jpeg
Size: 6844 bytes
Desc: image80b5f0.JPG
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140605/1241fb76/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image8da002.JPG
Type: image/jpeg
Size: 1074 bytes
Desc: image8da002.JPG
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140605/1241fb76/attachment-0003.jpe>