Add support for Compression Dictionary Transport (RFC 9842)

[arturobernalg]

Implement dictionary negotiation, storage, matching, and dcb / dcz decoding

[ok2c]

@arturobernalg This is a lot of new code. I will scan it for obvious programming errors or inefficiencies. I, however, cannot do a proper review as far as its conformance to the RFC is concerned. I will have to trust you know what you are doing.

One question, though. Is there a reason this is an async only feature?

[arturobernalg]

One question, though. Is there a reason this is an async only feature?
@ok2c
No fundamental reason. I initially limited the implementation to the async execution chain because that was the use case I was targeting and the capture/decoding code was based on AsyncDataConsumer. The protocol itself is equally applicable to the classic client, so the classic execution chain should support it as well.

[ok2c]

@arturobernalg I must admit i do not quite understand what is going on here, but some bits, especially header parsing ones do not good enough to me. I cannot make a call on this change-set

[ok2c]

@arturobernalg I have no objections, just one minor comment. This is now your area of responsibility.
Feel free to merge the change-set if you think it is ready or make symmetric changes to the classic transport first. Anyway, there is not much I can do beyond code conceptual sanity checks, parsing improvements, etc.

[arturobernalg]

One question, though. Is there a reason this is an async only feature?
@ok2c
No fundamental reason. I initially limited the implementation to the async execution chain because that was the use case I was targeting and the capture/decoding code was based on AsyncDataConsumer. The protocol itself is equally applicable to the classic client, so the classic execution chain should support it as well.

@ok2c I add the symmetric changes to the classic transport. Please do another pass

[ok2c]

@arturobernalg One can now generate massive change-sets that I simply have no physical ability to review line by line. As I said earlier, conceptually I have no objections to merging this pull request. But it is your area of responsibility. If you think it is ready, merge it now. If you think it is not ready, do not.

[garydgregory]

It seems odd to have compression implemented here. Why is this not reusing Commons Compress?

[arturobernalg]

It seems odd to have compression implemented here. Why is this not reusing Commons Compress?

Hi @garydgregory . commons compress current input stream APIs do not expose dictionary support.

[garydgregory]

It seems odd to have compression implemented here. Why is this not reusing Commons Compress?

Hi @garydgregory . commons compress current input stream APIs do not expose dictionary support.

Well, let's make it don't that then instead doing it here. What do you need? I am Commons committee and I can help make it happen.

[ok2c]

@arturobernalg Having a larger community to maintain this code would be a good thing. Moreover, you should also consider contributing the event driven compression / decompression code from our async transport to commons-compress for the same reason.

[arturobernalg]

@arturobernalg Having a larger community to maintain this code would be a good thing. Moreover, you should also consider contributing the event driven compression / decompression code from our async transport to commons-compress for the same reason.

Thanks @garydgregory . I’ll work with you on adding the required dictionary support to Commons Compress and then update this PR to reuse it.
@ok2c now what??? What should i do with this PR?

[ok2c]

@ok2c now what??? What should i do with this PR?

@arturobernalg I really cannot tell you what to do as I have no understanding of the underlying specification. If you think the feature is ready for 5.7 feel free to merge the pull request. Then, re-work the code and remove duplicated bits once there is a release of commons-compress with the required functionality. One important thing, commons-compress should remain optional at runtime. Alternatively, you way want to keep the pull request open until commons-compress is ready.

I really have no idea how important this feature is for the wider user population and therefore cannot tell what approach is better. I even had no idea this RFC existed.