Those are some good questions and I pondered them last night even
before I read your email.
Right now, if no transport layer is passed in a default one is used
for them. The don't make me think implementation is already there. If
you want to use something other than the default one than you need t
My comments are inline below...
On Fri, Jun 6, 2014 at 8:47 AM, Jamie Hannaford <
jamie.hannaf...@rackspace.com> wrote:
>Whether the same one is used for each service or a new one is used for
> each service doesn't matter.
>
>
> Yes, it does matter IMO - and here are the reasons why:
>
> 1
> 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?
I'm not in agreement and here is why (with a use case).
A transport client is concerned with transporting only. Whether the same
one is used for each
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
k
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 handle
