Make transport pluggable about jawampa

[Matthias247]

As @fasar already asked the same thing I will copy the response below:

Initially I started like what you like to do now - with making the transport layer pluggable and having the client and router classes independent of Netty.
However I then discovered that it made more trouble than I thought it was worth it - so I decided with hardwiring it to Netty.

The problems do not necessarily come from unifying the interface - that's quit simple. What is hard is that most I/O frameworks also have their own threading model and their own pipeline model.
E.g. Netty uses multiple singlethreaded eventloops in parallel - most times I stay in a thread but for the Router there is a hop. Play (and Akka in general) work different with using the Actor model.
Some Frameworks will expect a direct response to a request, other will allow to send it asynchronously.
For some a send will be a blocking operation, for others it will be non-blocking but will still happen immediatly, and for the last group it will be non-blocking and the actual action will be deferred.
And plugging the WampRouter on top of a Netty HTTP server so that it can run concurrently with normal HTTP on the same port might require a different model than running it concurrently with a Play HTTP provider.

Building in abstraction layers would also make some optimizations no longer possible that - e.g. more data would need to be copied (because some transports might mutate them later), more scheduler/executor hopping would be necessary and the optimized data structures from Netty could not longer be used.

Therefore I decided to avoid the extra complexity and just to go the Netty only road. I still think porting the whole thing on top of another layer would be easier than to provide a clean layered approach with pluggable transports.

[fasar]

Hello,

I've the same problem as you @nilskp.
I've do an effort to remove netty dependency.
The forked project is located at : https://github.com/fasar/jawampa/tree/parser

Be careful, this is the branch parser of jawampa.

This fork is less clean than @Matthias247 jawampa.
It has some unit test to understand.
I plan to add some javadoc.

++,
Fabien.

[nilskp]

@Matthias247 That makes sense. I think you could have made the assumption that the transport layer must always be async, since this is websockets. This might simplify things. Regarding optimizations, that's without a doubt true, as abstractions always incur such costs.
The only issue I see with your approach is that you've painted your project into a very small corner for usage, since most deployments are probably already running inside some other container. But if that's the scope, then so be it.

@fasar Looks like just the routing module, which is exactly what is interesting here. Too bad a fork is necessary though.