arnonmoscona / iqfeed Goto Github PK

EventPublisher is not a very good event model. Need to refactor to something like EventBus or MBassador

Currently the facade knows about the client. Most applications are not all that high performance as the original and I can afford to make things cleaner at some performance cost.

• use mbassador to publish events. Make sync or async a constructor function.
• client just subscribes to messages
• facade can be a supplier as well, probably by creating a simple subscriber that exposes a supplier which blocks until the next message
• the supplier can then become a stream simply by Stream.generate

The current code relies on tags and older jam features. It may be possible to

• leverage CompletableFuture and other jdk8 features
• tags should be more robust and should rely less on manual generation
• while I cannot get rid of tags entirely, as they must travel to iqfeed and back, there should be an easier way to do the setup
  ** more generalized way to create the response data and pending calls collections
  ** leverage lambdas to get rid of the need to create custom classes to represent each call type. Use a base class and a builder pattern.
  ** make the whole thing more fluent so that all the code for a single call can be in one place
  ** it would be best if the whole thing can be done a bit outside the iqfeed client core class so it is not so bloated and kept small. New calls should be basically bolted on to the base class
• should use RetryExecutor

The "inherited code" in the iqfeed project uses it's own weird dependency injection. For instance injecting a concrete IQFeed Facade class into the IQfeed client.

Need to use a third party dependency injection.

• Must be able to use mocks in testing
• Should make minimal assumptions on which 3rd party dependency injector should be used (not clear how easy that would be)

Remodel iqfeed client using java8 streams. Consider also using apache Camel as a processing pipeline.

Should also consider esper as it has very good support for windowing, such as what one would use for moving averages. Although another possibility is to find some extension of java8 streams that has windowing functions. Failing to find one it might be a good exercise to build one myself and publish it. Esper functionality might be a good feature guide for this.

Look also at http://pic.dhe.ibm.com/infocenter/streams/v2r0/index.jsp?topic=%2Fcom.ibm.swg.im.infosphere.streams.javadoc.api.doc%2Fdoc%2Findex.html (IBM infosphere streams window operator)

Also look at spark reduceByKeyAndWindow http://spark.apache.org/docs/0.9.1/streaming-programming-guide.html

The most important thing in this case is that the input stream and output stream may not be numbers. Input could be ticks and output could be bars (window size is not be fixed and can be zero) or it could be a bar stream to bar stream transformation.

The thing is that it may simply be a matter of using the built-in Collectors.groupingBy() method and some rather thin layer that is trading specific...