Feature/Question: Future API user usage - Pipeline (0.2.* version?)

[oxplay2]

Reason of this Question

• added "Feature: Better Serializer exception handling" and wanted add even more like "Feature: ReadTimeout".

Question:

For now, we have "wrapper"(NettyClient/NettyServer) that user can Extend to add custom changes, but generally just should use API to set it up.

I am afraid we will need add too many "configurable" Handlers into Settings, while Monkey-Netty user might want add it "himself"

Lets assume "LoggerHandler" that i recently added, now i also see ReadTimeoutHandler that might be helpfull.

Do you think we should:

• add ALL of this Handlers as wrapper features or allow user customize pipeline himself too?(and just provide Utility classes if needed and leave it to user)

or

• Should we make Monkey-Netty very user friendly and make API for every aspect of Handlers to be configurable in Settings.

or

• 50% / 50% - allow customizable, but also have "main ones"(logger/read-timeouts/etc) as configurable in Settings?

ofc, user can anyway "extend" and change pipeline, but then he would need copy-paste Monkey-Netty code too.

---

Feature Suggestion(1/3 options):

Most changes like logger / SSL / etc - are Monkey-Netty wrapper API that allow easy usage without wonder how to do something.

Thats nice. But i did thought that we should just allow user modify ChannelPipeline. (it is before he run Client/Server, but after constructor created object)

like

Server server = new Server([params]);
server.addPipelineModifier(someModifierInterface{ pipeline.addFirst(someUserCustomHandler); })
stateManager.add(server);

this way we can also Create our Utility Classes like:

class PipelineExceptionHandlerModifier(){

LogLevel logLevel;

PipelineExceptionHandlerModifier(LogLevel logLevel) {
     this.logLevel = logLevel;
}

public void modifyPipeline(Channel ch, Pipeline p) {
     p.addFirst(new LoggerHandler(logLevel)); 
     p.addFirst(new ExceptionOnFailureHandler()); 
}

}

or

class PipelineReadHandlerModifier(){

int readTimeout = 10;

PipelineReadHandlerModifier(int readTimeout) {
     this.readTimeout = readTimeout;
}

public void modifyPipeline(Channel ch, Pipeline p) {
     p.addFirst(new ReadTimeoutHandler(timeout)); 
}


}

While our "main pipeline" would be as "NetworkObjectHandlerModifier"

Since, even now, we are unable to send simple Integer, we always do it via Object. This way user could be able to setup as he needs.

Changes:

• add "CustomPipeline Interface with abstract void setupPipeline()" to be Set in Client/Server where it will be executed each "initChannel" after Monkey-Netty initalize default pipeline setup.

---

Since if we gonna stick with 2) option still, we will need a lot of new Settings, just now i thouight to add "Feature: ReadTimeout".

I think we should only provide API for basic functionality.

But generally this topic is, to understand the Direction Monkey-Netty need to go, if pipeline features will be Utility Classes or it will be Settings that decide about everything.