-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compression #1539
Compression #1539
Conversation
Signed-off-by: Heinz N. Gies <heinz@licenser.net>
Signed-off-by: Heinz N. Gies <heinz@licenser.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While i like the "unification" aspect, i do not see how it is a win for users to have to type a complex json config structure to chose a compression/decompression algo instead of having handy string shorthands.
"separate" => Ok(Box::new(separate::Separate::from_config(&config.config)?)), | ||
"base64" => Ok(Box::new(Base64::default())), | ||
"gzip" => Ok(Box::new(Gzip::default())), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't see how removing all those nice short-hands helps users. Now people need to type the very tedious:
{
"name": "compress",
"config": {
"algorithm": "gzip"
}
}
instead of just "gzip"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to also consider adding elementwise
vs stream
compression with making the compress
processor require a config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we discussed this morning, it reduces the surface we expose as a core, making it simpler, in favor of moving short-hands into userland with definable pre and post processors giving users the option to add syntax sugar to any degree they wish.
Regarding stream compression, so far all compressors have been element wise compression the PR doesn't look at or consider changing this but it'd be a nice ticket to add and consdier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it.
Lets also have a ticket for defining/creating pre/postprocessors in troy and then i'm good :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signed-off-by: Heinz N. Gies <heinz@licenser.net>
Pull request
Description
This unifies the various compression and decompression pre and postprocessors into a single pre and a single postprocessor.
Checklist
Performance
Rally just restructuring