[squid-dev] RFC Sourcelayout for clientStreams

[Alex Rousskov]

On 01/09/2017 12:21 AM, Amos Jeffries wrote:
> I've been looking at the clientStreams objects and moving them to a
> library for the SourceLayout project.
> 
> What I would like feedback on before I go and make a namespace and
> library up is whether we want to retain the term "Client Streams" as the
> name for that component or whether there is a better name?
> 
> * Maybe 'Body' from the BodyProducer/Consumer objects which are the two
> main endpoints of a clientstream so far.
> 
> * Maybe 'DataFlow' from the idea that it is for handling opaque data,
> and also the HTTP/2 frame name for the bytes transferred this way is DATA.
> 
> Any other ideas or keep ClientStreams?


It is difficult to correctly restructure and name an old API that should
not exist in the first place. Do we focus on what ClientStreams are used
for now? On what they can do now? Or should do in the future?

Focusing on what that API should eventually become is enticing but
dangerous, especially since I doubt we agree regarding that future. For
example, the replacement API might already exist (and just needs to be
used, with some adjustments/enhancements, instead of ClientStreams).

* "Body" is too generic to be usable for this purpose. Besides,
ClientStreams transfer not just bodies but entire responses IIRC.

* "DataFlow" is better but is still too general.

* "Client" should actually be "Server", but the API is more about
response delivery to the Server transaction than it is about the Server
transaction itself.

* "Stream" is already used for so many things that paring it with
something general like Client or Server does not help much.



I suggest punting and leaving ClientStream name as is for now and
dealing with it when that API is replaced.


HTH,

Alex.