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

Feature: Settings #12

Open
oxplay2 opened this issue Nov 18, 2020 · 5 comments
Open

Feature: Settings #12

oxplay2 opened this issue Nov 18, 2020 · 5 comments
Labels
feature Use when having a awesome idea

Comments

@oxplay2
Copy link

oxplay2 commented Nov 18, 2020

As discussed, we need to desgin a way to pass Monkey-Netty Settings.

There are multiple ways like:

  • Use JME AppSettings
    Disadvantage with this solution is that someone would not know that he can configure it there, unless he will read Monkey-Netty wiki.

  • use Java Properties
    Its String->String, instead String->Object so IMO bad solution for this one.

  • use own HashMap Settings class utility
    Disadvantage that we need additional class instead of using ready2use solutions.

Im not sure what would be your decision, but for me options 1 and 3 are fine.
If you have more options for Settings, please tell

@tlf30 tlf30 added the feature Use when having a awesome idea label Nov 19, 2020
@tlf30
Copy link
Owner

tlf30 commented Jan 15, 2021

We could use apache configurations 2, I have used it on other projects and it works good. We could have a network.properties file.

@oxplay2
Copy link
Author

oxplay2 commented Jan 15, 2021

as a global settings, sounds good.

But what about "per Server/Client" settings?

For example some Client might want have high timeout value, while other low value.
Same about servers, since each might want different settings.

Do apache configurations 2 will allow this for Monkey-Netty?

@tlf30
Copy link
Owner

tlf30 commented Jan 15, 2021

Hmm, apache configuration 2 would be fine for global settings, but not on a per server/client basis.

@tlf30
Copy link
Owner

tlf30 commented Feb 25, 2021

@oxplay2 I have created an initial implementation for settings.
I am still playing with it. I will probably make it a hashmap wrapper before I am done, but right now I am playing with how the architecture needs to change to accommodate this.

See #35 for my initial implementation. It does have some large changes to the architecture, which I have been wanting to do for some times anyways. But to implement these changes they were required. I will probably cut a v1.0.0 release for this, along with a couple other features I want to implement that will be breaking changes.

EDIT: The other big feature I want in v1.0.0 is #15. And I think this changes will make that easier to implement.

@oxplay2
Copy link
Author

oxplay2 commented Feb 26, 2021

thanks for notification :)

sounds good, no rush, this should be done very well, so take time to make it clever way. Settings can wait until you finish other things too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Use when having a awesome idea
Projects
None yet
Development

No branches or pull requests

2 participants