Protocols as Projects #18
Comments
|
This also makes more sense for transports since there is little to no commonality across protocols. For example, Servlet 3.1 as a transport can only be used for HTTP. |
|
Considering the disparate protocols, it makes sense to separate. That said would there be no shared code across protocols (working with buffers, connection lifecycle handling, etc) and across transport implementations? Or do you see the TCP module as that lowest common denominator? Would WebSocket be under ripc-http? A WebSocket connection starts with an HTTP handshake and is likely mapped (and secured) under a shared URL hierarchy within a (single) Web application process. On the other hand beyond that the actual handling of WebSocket is much closer to TCP. There is nothing to reflect the JVM nature any more with the "-jvm" suffix gone. Perhaps that suffix still makes sense to have on each new proposed repository? For the "spi" vs "apis" naming, I think the distinction could be confusing depending on who is looking at this and it's also somewhat prescriptive in assuming how reactive-ipc would be used. Perhaps it would be more clear to call what is proposed as |
There probably will be some, such as base implementations of Perhaps an "ripc-core" project could be used for that?
No I don't. HTTP for example should not be based on that as the transports will handle that implementation on top of TCP. UDP also wouldn't work on TCP.
I think so. My view is that HTTP should be multi-protocol to support HTTP/1.1, HTTP/2, WebSocket, and SSE.
Sure, that makes sense.
That seems good to me. I wasn't thrilled with the "spi" naming anyways. |
|
Modified names based on discussion above:
|
Yeah we should have ripc-core where we can have different modules like ripc-buffer, ripc-reactive-streams, etc and we can discuss these modules as and when the need arises. Re: TCP being the LCD.
I see 2 above to be more meaningful as opposed to 1. Re: WS, HTTP/2 & HTTP relationship. I think HTTP/1.1 implementation should provide a Upgrade/Downgrade facility for server and client respectively, as per the generic HTTP upgrade semantics. We can decide then whether HTTP/2, WS exist in the same project or not. I can see HTTP/2 moving faster than HTTP/1.1 implementation from the nature of the protocol maturity itself and us understanding the usecases for it. That may have us separating HTTP/2 from HTTP/1.1 project purely from the perspective of release cycles. |
Those should be adapter (vs adaptor), right?
Perhaps separate modules but they should be the same project. Whatever the split it should be possible to run a single server with HTTP 1.1, HTTP 2 and WebSocket support. |
Absolutely, that's a given! |
No idea ... they seem interchangeable: |
Yup. |
|
Heh, good point. FWIW adapter seems to be preferred in JDK classes at least. Lots of matches on |
|
Then "adapter" it is! |
As @NiteshKant and I have been playing with code this week it seems that we should separate protocols as projects (repos), not just modules. This would allow them to have different release and versioning cycles, which is important as the coming years will evolve and add things.
We suggest that instead of "reactive-ipc-jvm" being the home of everything, we add top level projects as protocols arrive such as:
ripc-tcp
With submodules as ...
ripc-http
With submodules as ...
ripc-udp
ripc-kafka
ripc-cassandra
ripc-dynomite
ripc-memcached
etc
The text was updated successfully, but these errors were encountered: