{"action":"created","issue":{"url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/10","labels_url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/10/labels{/name}","comments_url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/10/comments","events_url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/10/events","html_url":"https://github.com/reactive-ipc/reactive-ipc-jvm/issues/10","id":60780001,"number":10,"title":"Need of the `Buffer` abstraction","user":{"login":"NiteshKant","id":820005,"avatar_url":"https://avatars.githubusercontent.com/u/820005?v=3","gravatar_id":"","url":"https://api.github.com/users/NiteshKant","html_url":"https://github.com/NiteshKant","followers_url":"https://api.github.com/users/NiteshKant/followers","following_url":"https://api.github.com/users/NiteshKant/following{/other_user}","gists_url":"https://api.github.com/users/NiteshKant/gists{/gist_id}","starred_url":"https://api.github.com/users/NiteshKant/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/NiteshKant/subscriptions","organizations_url":"https://api.github.com/users/NiteshKant/orgs","repos_url":"https://api.github.com/users/NiteshKant/repos","events_url":"https://api.github.com/users/NiteshKant/events{/privacy}","received_events_url":"https://api.github.com/users/NiteshKant/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-03-12T07:13:10Z","updated_at":"2015-03-12T13:44:45Z","closed_at":null,"body":"@jbrisbin mentions the intention of this abstraction [here](https://github.com/reactive-ipc/reactive-ipc-jvm/issues/3#issuecomment-78257505) as follows:\r\n\r\n>>> I also added a Buffer abstraction in core. I put it in the javadoc but it should be noted that a Buffer in ripc terms does not mean just a variation on byte[] or ByteBuffer. The only (partial) implementation that exists right now is one based on Netty's ByteBuf, but the Buffer abstraction itself doesn't care what the underlying data actually is. It could be a Buffer<Frame> or a Buffer<Pojo>. This will provide simple read-and-convert functionality for common things like length-field-based encoding that uses Snappy or Zip compression, etc... that's going to be nearly identical for all use cases.\r\n\r\nI am unclear about why would we have to provide data encoding/decoding via a common interface agnostic of networking libraries. I would imagine the codecs naturally fitting with a networking library interface and general length-field-based codecs are already available with netty.\r\n\r\nCurrently, this `Buffer` is a part of the [`Connection`](https://github.com/reactive-ipc/reactive-ipc-jvm/blob/master/ripc-protocol-tcp/src/main/java/io/ripc/protocol/tcp/Connection.java) as:\r\n\r\n```java\r\npublic interface Connection<B> extends Publisher<Buffer<B>>\r\n```\r\n\r\nThis means that everything read from a connection is always wrapped in this `Buffer`. Is this a valid contract? IMO it is too opinionated."},"comment":{"url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/comments/78481538","html_url":"https://github.com/reactive-ipc/reactive-ipc-jvm/issues/10#issuecomment-78481538","issue_url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/10","id":78481538,"user":{"login":"jbrisbin","id":55797,"avatar_url":"https://avatars.githubusercontent.com/u/55797?v=3","gravatar_id":"","url":"https://api.github.com/users/jbrisbin","html_url":"https://github.com/jbrisbin","followers_url":"https://api.github.com/users/jbrisbin/followers","following_url":"https://api.github.com/users/jbrisbin/following{/other_user}","gists_url":"https://api.github.com/users/jbrisbin/gists{/gist_id}","starred_url":"https://api.github.com/users/jbrisbin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jbrisbin/subscriptions","organizations_url":"https://api.github.com/users/jbrisbin/orgs","repos_url":"https://api.github.com/users/jbrisbin/repos","events_url":"https://api.github.com/users/jbrisbin/events{/privacy}","received_events_url":"https://api.github.com/users/jbrisbin/received_events","type":"User","site_admin":false},"created_at":"2015-03-12T13:44:45Z","updated_at":"2015-03-12T13:44:45Z","body":"We don't need a separate module for an interface that `extends Publisher<T>`, we could simply expose that directly from a wrapper around Netty.\r\n\r\nWe had a discussion with some members of our team around this and a point @rstoyanchev brought up is a good one: if we're building a generic and reusable core, then our intention is that people **not** use the Netty API directly. Otherwise why abstract it at all and why go to the trouble of splitting anything up? If we're not going to have common and reusable functionality in any of these other components, then this project itself has no purpose. You can easily create an RS implementation right on top of Netty and simply expose the RS interfaces instead of the Netty ones. There is no need for other modules and other levels of abstraction if that's the case.\r\n\r\nIMO we should **not** assume that all codecs are configured on the Netty pipeline and that the message being passed to the RS pipeline is one of the output type by the Netty codec and not the \"lowest common denominator\". This would immediately preclude the use of any implementation other than Netty unless it also provided its own, proprietary way of doing the common task of requesting that a chunk of bytes (which it would never access directly since it would get that through the `Buffer` abstraction) be turned into a useful object (which it would also never know about, nor touch, other than to pass it through to the next component in the pipeline). Without some kind of wrapper abstraction to represent the incoming data, there is simply no way for a generic component to interact with it other than to cast it to a real type, which could only be done in user code or in the implementation module.\r\n\r\nAgain we're back to the issue of: why bother with this exercise **at all** if we aren't going to abstract any of this \"common\" functionality away from Netty? It can't really be all that common if we are depending on Netty itself to do every bit of heavy lifting, from dispatching signals to decoding data."}}