{"action":"created","issue":{"url":"https://api.github.com/repos/reactor/reactive-streams-commons/issues/1","repository_url":"https://api.github.com/repos/reactor/reactive-streams-commons","labels_url":"https://api.github.com/repos/reactor/reactive-streams-commons/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/reactor/reactive-streams-commons/issues/1/comments","events_url":"https://api.github.com/repos/reactor/reactive-streams-commons/issues/1/events","html_url":"https://github.com/reactor/reactive-streams-commons/issues/1","id":123580126,"number":1,"title":"Design considerations","user":{"login":"akarnokd","id":1269832,"avatar_url":"https://avatars.githubusercontent.com/u/1269832?v=3","gravatar_id":"","url":"https://api.github.com/users/akarnokd","html_url":"https://github.com/akarnokd","followers_url":"https://api.github.com/users/akarnokd/followers","following_url":"https://api.github.com/users/akarnokd/following{/other_user}","gists_url":"https://api.github.com/users/akarnokd/gists{/gist_id}","starred_url":"https://api.github.com/users/akarnokd/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/akarnokd/subscriptions","organizations_url":"https://api.github.com/users/akarnokd/orgs","repos_url":"https://api.github.com/users/akarnokd/repos","events_url":"https://api.github.com/users/akarnokd/events{/privacy}","received_events_url":"https://api.github.com/users/akarnokd/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/reactor/reactive-streams-commons/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-12-23T00:18:07Z","updated_at":"2016-02-03T09:51:18Z","closed_at":null,"body":"There are a few decisions to be made:\r\n\r\n1) Repo initialization with Gradle files and directories\r\n\r\nWho should do this? I have a gradle setup I usually copy into new projects that can upload to maven based on local settings.\r\n\r\n2) Rackage naming, structure\r\n\r\nWhat should be the base package name. In addition, we may need an `internal` package.\r\n\r\n3) Lock-free or not?\r\n\r\nMost serializing operators can be implemented in both ways but lock-free usually requires lock-free queues (i.e., JCTools).\r\n\r\nThe project states it wants to avoid queue-use so we don't lock in on Disruptor or JCTools but is it possible to abstract away the queue operations, i.e., is the j.u.c.Queue interface an adequate abstraction?\r\n\r\nWe can also have implementations for both cases in separate subpackages `lockfree` and `locking`.\r\n\r\n4) Which Java version?\r\n\r\nJava 8 allows nicer code but Java 6 allows Android use.\r\n\r\n5) Processor implementations\r\n\r\nDo we want to provide these as well? Note that the operator `redo` - which unifies retry and repeat behavior through the signal of a Publisher requires a PublishProcessor at least (or a BehaviorProcessor at most), although these may be inlined.\r\n\r\n6) Factory or classes\r\n\r\nShould the library provide the operators via factory methods, i.e., `Publisher<R> map(Publisher<T> source, Function<T, R> mapper);` or as named classes: `class PublisherMap<T, R>`?\r\n\r\nThe latter case helps discovering what's in a chain.\r\n\r\n7) Operator fusion\r\n\r\nI'm in a relatively early stage of describing and prototyping operator fusion. What's definitely necessary is that each operator has a distinct class which also exposes its input parameters (i.e., the source and mapper in 6))\r\n\r\n8) Beta/Experimental annotation\r\n\r\nDo we want to copy the RxJava way of introducing new operators/classes?\r\n\r\n9) Benchmarks\r\n\r\nDo we want JMH benchmarks in the repo?\r\n\r\n10) Reactive-Streams TCK\r\n\r\nI have two problems with it: a) requires TestNG which is quite invasive in Eclipse and b) is designed to test either `just` and a replaying-type Processor implementation. It doesn't work properly for `range` for example because the test wants to verify if the output of the Publisher is the same as the test generated.\r\n\r\n11) Optimizations vs Reactive-Streams spec\r\n\r\nCertain internal operator optimizations, such as reusing a Subscriber instance, may violate the specification although completely safe to do.\r\n\r\nThe spec says that you can't subscribe the same instance multiple times to the same or different Publishers and some implementations may actually check for this (such as RxJavaReactiveStreams).\r\n\r\n12) Inlining and API leaks\r\n\r\nTo avoid allocations, some operators may build upon existing classes or implement interfaces that leak into the API. For example, an auto-sharing operator `PublisherAutoShare` may extend `AtomicInteger` directly to save on an atomic counter field. However, this class now has a bunch of other methods that leaked in and requires extra care from the users\r\n\r\n13) Building blocks\r\n\r\nThere are a few frequent building blocks useful for operators (i.e., arbiters, terminal atomics tools). Do we want to officially support them as well or keep them hidden in `internal`?\r\n\r\n14) Field updaters, Atomic instances or Unsafe?\r\n\r\nWhich technique do we want? Note that Java 8 is about to receive performance optimizations targeting field updaters so they get very close to Unsafe."},"comment":{"url":"https://api.github.com/repos/reactor/reactive-streams-commons/issues/comments/179133844","html_url":"https://github.com/reactor/reactive-streams-commons/issues/1#issuecomment-179133844","issue_url":"https://api.github.com/repos/reactor/reactive-streams-commons/issues/1","id":179133844,"user":{"login":"smaldini","id":76718,"avatar_url":"https://avatars.githubusercontent.com/u/76718?v=3","gravatar_id":"","url":"https://api.github.com/users/smaldini","html_url":"https://github.com/smaldini","followers_url":"https://api.github.com/users/smaldini/followers","following_url":"https://api.github.com/users/smaldini/following{/other_user}","gists_url":"https://api.github.com/users/smaldini/gists{/gist_id}","starred_url":"https://api.github.com/users/smaldini/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/smaldini/subscriptions","organizations_url":"https://api.github.com/users/smaldini/orgs","repos_url":"https://api.github.com/users/smaldini/repos","events_url":"https://api.github.com/users/smaldini/events{/privacy}","received_events_url":"https://api.github.com/users/smaldini/received_events","type":"User","site_admin":false},"created_at":"2016-02-03T09:51:18Z","updated_at":"2016-02-03T09:51:18Z","body":"I think these questions are getting answered now but some might need more exploration :\r\n\r\n11) Optimizations vs Reactive-Streams spec\r\n\r\nCertain internal operator optimizations, such as reusing a Subscriber instance, may violate the specification although completely safe to do.\r\n\r\nThe spec says that you can't subscribe the same instance multiple times to the same or different Publishers and some implementations may actually check for this (such as RxJavaReactiveStreams).\r\n\r\n12) Inlining and API leaks\r\n\r\nTo avoid allocations, some operators may build upon existing classes or implement interfaces that leak into the API. For example, an auto-sharing operator PublisherAutoShare may extend AtomicInteger directly to save on an atomic counter field. However, this class now has a bunch of other methods that leaked in and requires extra care from the users\r\n\r\nBut we can address them more naturally in separate issues if necessary.\r\n"}}