Skip to content
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

StringCodec.java #20

Closed
wants to merge 5 commits into from
Closed

StringCodec.java #20

wants to merge 5 commits into from

Conversation

Tokarak
Copy link

@Tokarak Tokarak commented Jun 19, 2022

resolves: #13
Replaces StringCodec.groovy with StringCodec.java

Tokarak added 3 commits June 19, 2022 17:59
My eye skipped over the Groovy script and CombinedChannelDuplexHandler; that will be coming up in a commit shortly. Oh well, it's not wasted work if you learnd from it.
@Tokarak Tokarak changed the title Stringcodec StringCodec.java Jun 19, 2022
@Tokarak
Copy link
Author

Tokarak commented Jun 19, 2022

I will also remove Encoder/Decoder, to save space and avoid confusing newcomers. I do not see when you would need only one of them, and high level users can type in the classname. If you disagree, rebase this commit out of the merge.

Tokarak added 2 commits June 19, 2022 18:55
Use StringCodec for most cases, or type the classname in manually.
@Tokarak
Copy link
Author

Tokarak commented Jun 19, 2022

If common protocols are transferred from groovy scripts to statically typed implementations, that would be a step towards documentation.

@RoganDawes
Copy link
Collaborator

For what it is worth, I created the groovy implementation to serve as an example of how to create your own ScriptHandlers. And it can absolutely be possible to have a StringDecoder or StringEncoder by itself. For example, a protocol that reads the name of an image, and responds with the image itself.
It is absolutely true that many people will simply go with the StringCodec, though, which is why that was also provided.
I think perhaps a better/bigger change might be to group symmetric codecs in one tab, and independent Encoders and Decoders in an adjacent tab? What do you think?

@Tokarak
Copy link
Author

Tokarak commented Jun 19, 2022

The best organisation may be by protocol, grouping into String, Http, Ssl etc.; provides a sensible organisation for the (future) docs too, and makes it easier to import an external set of Handlers for a protocol (which won't be stored here if the project ever reaches a large size); in short, scalable.
I think again each class should be wrapped somehow to allow automation of the templates.

@RoganDawes RoganDawes closed this Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement StringCodec and others using CombinedChannelDuplexHandler
2 participants