Considered adding compression functionality
Closed this issue · 9 comments
name: Feature request
about: Considered adding compression functionality
Is your feature request related to a problem? Please describe.
Not exactly a problem, but an interesting use case. We're implementing a messaging strategy between headquarters and several ships. The ships / vessels can be disconnected for longer periods, so Azure Service Bus queuing is a good option. We're facing bigger messages than 256kB, so claim-check pattern (this library) has already been discussed. In some area's, the vessels have very limited bandwidth, because of poor network connectivity. Next to that, internet connection can be very expensive in several area's. That's why we consider zipping the message locally on the ship, before sending it to service bus and unzipping it on the receiver side, in order to save bandwidth and costs.
Describe the solution you'd like
I guess it makes sense to foresee an option to enable compression, because it assists in such situations and also in case of really big files.
Describe alternatives you've considered
Doing it outside of the plugin, but would be a good that this is handled transparently by the plugin.
I'm curious - Why would you want to have this in this plugin over a plugin that runs before this one?
@SeanFeldman I'm presuming you can plugins here, that's the case right?
I'm curious - Why would you want to have this in this plugin over a plugin that runs before this one?
@ToonVanhoutte I'm guessing payload, even if compressed, still can surpass message max length. Is that the case?
I'm presuming you can plugins here, that's the case right?
@tomkerkhove your question seems to be missing something. Want to repeat?
That's right but I'm more wondering why you would want to have the compression as part of this plug in or if another plug in would make more sense.
My question was if you can chain plug-ins to a sort of pipeline or not. (I think but not sure) That's why I would split this to have one plug in per use case.
Anyway, was just curious!
@SeanFeldman: yes indeed, claim-check as such will still be needed, even after compression.
The more I think about this, the more I think a ServiceBus.CompressionPlugin would make more sense to be honest. This one can work on the result of that but should just apply the claim check pattern
Thanks @ToonVanhoutte. In that case what @tomkerkhove is saying is correct. Similar to "prefer composition over inheritance", it would make more sense to have a separate plugin with a sole responsibility to compress data.
A few more questions to get better understanding
- Would you say any message going of a vessel would need to be compressed, or there's be some condition?
- If there's any conditions, what those would look like?
- Would it matter what compression algorithm is used?
@ToonVanhoutte you didn't get back to me on these questions. From those, I'm more curious about compression algorithms you intend to use.
The preview of ServiceBus.CompressionPlugin is available.
For bugs and feedback, use ServiceBus.CompressionPlugin issue tracker.
Really great, Sean :-) I must have missed your previous questions! I'll answer them in the new repo!