{"action":"created","issue":{"url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/40","labels_url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/40/labels{/name}","comments_url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/40/comments","events_url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/40/events","html_url":"https://github.com/ReactiveSocket/reactivesocket/issues/40","id":102640333,"number":40,"title":"Are the request types too prescriptive?","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":"closed","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-08-23T17:45:10Z","updated_at":"2015-08-27T17:22:00Z","closed_at":"2015-08-27T17:22:00Z","body":"The more I think about our current model of defining types of interaction (Fire n forget, Request-Response, Request-Stream, Request-Subscription), it appears to me that we are being too prescriptive. We may finally end up addressing all cases by incrementally adding things like REQUEST_CHANNEL (#30) but the question is, does it belong to the protocol? \r\n\r\nOne way to answer this question would be as to what value add does it have. I believe the semantics of what kind of interaction it is, are defined while creating an endpoint and does not change while actually invoking that endpoint. e.g.: An endpoint defined as request and response does not convert to request stream upon invocation. So, is passing this type over the wire meaningful?\r\n\r\nIrrespective of whether we define these interaction types, I think there are two important constructs this protocol is establishing today:\r\n\r\n- How to multiplex requests (define loosely as a stateful interaction between RQ and RS) over the same connection by attaching the context of the request (request/stream ID) to each data exchange (frame).\r\n\r\n- Define how data is exchanged over the wire; by defining the framing semantics for the exchange.\r\n\r\nIf we instead define the protocol as the above two (eliminating the specific interaction types), the protocol will be more flexible and will not force people to fit their requirements into specific interaction types. The interaction types will be defined by the usage like:\r\n\r\n##### Request-Response\r\n```java\r\nreactiveSocket.request() /*Initiate new stream*/\r\n                        .write(request data)\r\n                        .continueWith(response)\r\n                        .take(1)\r\n\r\n```\r\n##### Fire and Forget\r\n```java\r\nreactiveSocket.request() /*Initiate new stream*/\r\n                        .write(request data)\r\n\r\n```\r\n##### Request-Stream\r\n```java\r\nreactiveSocket.request() /*Initiate new stream*/\r\n                        .write(request data)\r\n                        .continueWith(response)\r\n                        .take(n)\r\n\r\n```\r\n\r\n##### Request-Subscription\r\n```java\r\nreactiveSocket.request() /*Initiate new stream*/\r\n                        .write(request data)\r\n                        .continueWith(response)\r\n\r\n```\r\n\r\n##### Request-Channel\r\n```java\r\nreactiveSocket.request() /*Initiate new stream*/\r\n                        .write(request data subject)\r\n                        .continueWith(response)\r\n\r\n```\r\n\r\nI do believe though that such interaction models are useful while defining client and server libraries, such as developed under reactivesocket-java.\r\n"},"comment":{"url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/comments/135497885","html_url":"https://github.com/ReactiveSocket/reactivesocket/issues/40#issuecomment-135497885","issue_url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/40","id":135497885,"user":{"login":"benjchristensen","id":813492,"avatar_url":"https://avatars.githubusercontent.com/u/813492?v=3","gravatar_id":"","url":"https://api.github.com/users/benjchristensen","html_url":"https://github.com/benjchristensen","followers_url":"https://api.github.com/users/benjchristensen/followers","following_url":"https://api.github.com/users/benjchristensen/following{/other_user}","gists_url":"https://api.github.com/users/benjchristensen/gists{/gist_id}","starred_url":"https://api.github.com/users/benjchristensen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benjchristensen/subscriptions","organizations_url":"https://api.github.com/users/benjchristensen/orgs","repos_url":"https://api.github.com/users/benjchristensen/repos","events_url":"https://api.github.com/users/benjchristensen/events{/privacy}","received_events_url":"https://api.github.com/users/benjchristensen/received_events","type":"User","site_admin":false},"created_at":"2015-08-27T17:22:00Z","updated_at":"2015-08-27T17:22:00Z","body":"Discussed in person ... we reviewed the experience of implementing reactivesocket-java and how knowledge of interaction models allows performance optimizations. Also, the admittedly subjective choice of what interaction we consider building blocks for all apps using this protocol.\r\n\r\nClosing out and retaining the 5 interaction models we've specced."}}