[alexanto]

this is just a rename from transport -> api_client, because i would like to reuse the name transport for sth else
i want to split the current transport into multiple parts, the api_client handling some unleash specific logic, like etags, event and the transport layer only responsible for the actual request so it is possible to swap to a custom one

[sighphyre]

Yup, looks like a rename to me

[sighphyre]

i want to split the current transport into multiple parts, the api_client handling some unleash specific logic, like etags, event and the transport layer only responsible for the actual request so it is possible to swap to a custom one

I don't disagree, just keep an eye on how deeply abstracted this gets. This SDK got a whole bunch of complexity in a short space of time to support the async client. I'm hoping we can throw away some of the internal abstractions out once we feel comfortable that we know where we want to go. Not putting more on your plate, just keep half an eye open for abstractions you feel aren't pulling their weight as you refactor

[alexanto]

I'm hoping we can throw away some of the internal abstractions out once we feel comfortable that we know where we want to go

i have a feeling that I would like to know where streaming goes first, but generally agree