search

reactive-ipc / reactive-ipc-jvm

Reactive IPC for the JVM
Apache License 2.0
55 stars 13 forks source link

Protocols as Projects #18

Open benjchristensen opened 9 years ago

benjchristensen commented 9 years ago

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:

benjchristensen commented 9 years ago

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.

rstoyanchev commented 9 years ago

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 ripc-tcp-spi the API of reactive-ipc and anything "-rxjava1" an adapter layer. In other words: ripc-tcp-spi => ripc-tcp-api ripc-tcp-apis => ripc-tcp-adapter

benjchristensen commented 9 years ago

would there be no shared code across protocols

There probably will be some, such as base implementations of Publisher. Possibly Buffer as well. As we implement 2 or 3 protocols we'll find what is common.

Perhaps an "ripc-core" project could be used for that?

Or do you see the TCP module as that lowest common denominator?

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.

Would WebSocket be under ripc-http?

I think so. My view is that HTTP should be multi-protocol to support HTTP/1.1, HTTP/2, WebSocket, and SSE.

Perhaps that suffix still makes sense to have on each new proposed repository?

Sure, that makes sense.

Perhaps it would be more clear to call what is proposed as ripc-tcp-spi the API of reactive-ipc and anything "-rxjava1" an adapter layer

That seems good to me. I wasn't thrilled with the "spi" naming anyways.

benjchristensen commented 9 years ago

Modified names based on discussion above:

NiteshKant commented 9 years ago

Perhaps an "ripc-core" project could be used for that?

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 think there are two aspects to it:

  1. The relation appearing in the APIs (HTTP extends TCP)
  2. The relation appearing in an implementation.

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.

rstoyanchev commented 9 years ago

ripc-tcp-adaptors

Those should be adapter (vs adaptor), right?

We can decide then whether HTTP/2, WS exist in the same project or not.

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.

NiteshKant commented 9 years ago

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!

benjchristensen commented 9 years ago

Those should be adapter (vs adaptor), right?

No idea ... they seem interchangeable:

benjchristensen commented 9 years ago

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!

Yup.

rstoyanchev commented 9 years ago

http://en.wikipedia.org/wiki/Adapter#cite_note-1

Heh, good point. FWIW adapter seems to be preferred in JDK classes at least. Lots of matches on "java.*.Adapter" and none on "java.*.Adaptor".

benjchristensen commented 9 years ago

Then "adapter" it is!