{"action":"created","issue":{"url":"https://api.github.com/repos/reactive-streams/reactive-streams-jvm/issues/268","labels_url":"https://api.github.com/repos/reactive-streams/reactive-streams-jvm/issues/268/labels{/name}","comments_url":"https://api.github.com/repos/reactive-streams/reactive-streams-jvm/issues/268/comments","events_url":"https://api.github.com/repos/reactive-streams/reactive-streams-jvm/issues/268/events","html_url":"https://github.com/reactive-streams/reactive-streams-jvm/issues/268","id":77756823,"number":268,"title":"Add Promise style semantics to reactive streams","user":{"login":"daviddawson","id":206276,"avatar_url":"https://avatars.githubusercontent.com/u/206276?v=3","gravatar_id":"","url":"https://api.github.com/users/daviddawson","html_url":"https://github.com/daviddawson","followers_url":"https://api.github.com/users/daviddawson/followers","following_url":"https://api.github.com/users/daviddawson/following{/other_user}","gists_url":"https://api.github.com/users/daviddawson/gists{/gist_id}","starred_url":"https://api.github.com/users/daviddawson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/daviddawson/subscriptions","organizations_url":"https://api.github.com/users/daviddawson/orgs","repos_url":"https://api.github.com/users/daviddawson/repos","events_url":"https://api.github.com/users/daviddawson/events{/privacy}","received_events_url":"https://api.github.com/users/daviddawson/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":39,"created_at":"2015-05-18T18:30:53Z","updated_at":"2015-11-15T02:05:39Z","closed_at":null,"body":"We are currently building a set of network APIs that use reactive streams. We're migrating more and more over the reactive streams to gain the benefits of swappable implementations over the standardised interfaces, back pressure support and good FRP.\r\n\r\nWhen dealing with streaming data, the semantics are well understood by the users of the API. When dealing with something that is naturally request/ response (think similar to an HTTP request), then the semantics begin to break down.  \r\n\r\nWe used a Future for this reason. Developers approaching the API expect to get a single response back, and we feel that the API should indicate to them what they should expect to happen. It's about reasoning and learning rather than mechanics.\r\n\r\nNaturally, we would want to return a Promise from this type of API, indicating to the developer what they can reasonably expect to occur.  Currently, our only option from reactive streams is a full publisher.  \r\n\r\nMechanically, this works fine, but that isn't the issue. From the point of view of building an API for consumption by randoms on the internet, I don't want to have to indicate in the method name nor the documentation that a single item will be returned.\r\n\r\nThe case of up to 1 item being returned is special, and has spawned Future and Promise in the JDK and everywhere else respectively. For this reason, and for reactive streams to become even more useful for the developing of highly interoperable and usable APIs, I would like to suggest that a Promise interface be added to the core set.\r\n\r\nMechnically, it would be an extension of Publisher, and nothing more. Semantically, it would be constrained in the specification to return up to a single item.\r\n"},"comment":{"url":"https://api.github.com/repos/reactive-streams/reactive-streams-jvm/issues/comments/156770185","html_url":"https://github.com/reactive-streams/reactive-streams-jvm/issues/268#issuecomment-156770185","issue_url":"https://api.github.com/repos/reactive-streams/reactive-streams-jvm/issues/268","id":156770185,"user":{"login":"wenerme","id":1777211,"avatar_url":"https://avatars.githubusercontent.com/u/1777211?v=3","gravatar_id":"","url":"https://api.github.com/users/wenerme","html_url":"https://github.com/wenerme","followers_url":"https://api.github.com/users/wenerme/followers","following_url":"https://api.github.com/users/wenerme/following{/other_user}","gists_url":"https://api.github.com/users/wenerme/gists{/gist_id}","starred_url":"https://api.github.com/users/wenerme/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wenerme/subscriptions","organizations_url":"https://api.github.com/users/wenerme/orgs","repos_url":"https://api.github.com/users/wenerme/repos","events_url":"https://api.github.com/users/wenerme/events{/privacy}","received_events_url":"https://api.github.com/users/wenerme/received_events","type":"User","site_admin":false},"created_at":"2015-11-15T02:05:39Z","updated_at":"2015-11-15T02:05:39Z","body":"Above comment is for single event process, I think these is no need for a whole stream promise, you can do this by a subscribtion."}}