dstanesc

This is an excellent discussion starter and can work conceptually pretty well with the existing implementation (ie. Property tree summarizer draws efficiency by maximizing blob size to the platform limits...

I was touching the topics above, but probably more clarification on the presented viewpoint won't hurt: > I have a feeling that there will always be some optimal threshold and...

@tylerbutler Sorry for the confusion, it is my failure in expressing our people concerns. 1. This is just a documentation enhancement needed by our engineers. 2. The new client will...

@tylerbutler We can definitely help with the code review. Thank you very much for the pro-activeness!

Yes, it looks like for the transfer of the payloads we have in mind today for larger data (chunking considered) and the available network speed `lz4` adds the least overhead....

@evaliyev @ruiterr @nedalhy Wondering whether this defect was addressed elsewhere or still a problem?

> However we might also want to compress the complete summary to get the most from the compression algorithm. Please account that in the context of the [larger goal](https://github.com/microsoft/FluidFramework/issues/10494) incrementality...

> Incrementality can still be kept if compression is used only for the transfer. Two level compression and logically decoupling transfer from storage compression is indeed a very interesting idea.

> As an FYI, @noencke is beginning to work on incremental summaries (but not compression.) @DLehenbauer @noencke Because of its relevance to large data agenda we would like to stay...

Thanks @DLehenbauer for looking into it and confirming the theoretical aspects. We can definitely build upon this special ability of `LZ4` to compress relatively well, be fast and stay stable....