XChange 4.0.0 Wishlist

[timmolter]

1. Check that no implementations are leaking exchange-specific Exceptions ( See #1233) 1. Create builders for all generic DTOs (most have a builder) 1. Figure out metadata and init() solution 1. Remove deprecated code

1. Look at TODOs

[rafalkrupinski]

How about changing cancelOrder return type to void?

[mmazi]

What's the timeframe for releasing 4.0.0? I'd like to contribute some things that I'd like to see improved, but need to set some time aside to do it.

EDIT: here's my list (will be adding issues as they come to mind):

1. Improve the Exchange and ExchangeSpecification creation/config API (String class name parameter, set/apply/default specification methods) (I'll open a separate issue or create a PR to clarify)
2. Make the generic API consistent in terms of the currency pair (#1068)
3. Clearly describe the semantics of the parameters and return values of the generic methods and fields of generic DTOs, where this is still missing
4. PollingTradeService.cancelOrder should probably be void and always throw an exception on error.
5. Unified and well-defined exception API (#1233)
6. Merge TradeHistoryParamOffset and TradeHistoryParamPaging. Unify the Integer/Long param type discrepancies. Provide a default implementation that converts between limit+offset and page+pageLength. Document 0- or 1-based indexing.
7. Include some standard json serializers/deserializers, eg. for Currency (eg. XBT <-> BTC), CurrencyPair (to support different formats like BTCUSD, btc_usd, USD/BTC etc.), Order.OrderType etc.
8. Review date parsing, especially time zones (eg. Bitstamp's implementation is incorrect -- my fault).

[timmolter]

I don't have a time frame in mind. Definitely not in the next month or two. Some time afterwards hopefully though.

[jheusser]

• make all exchange parameters configurable via exchangeSpecificParameters. It would be nice to be able to override the defaults for host, ssl uri, plain text uri, uri streaming. Also not sure if those names are as specific/descriptive as they could be. Perhaps we can have some default keys in the map which provide rest host, streaming hostname etc.
• I think the main interfaces PollingTradeService and PollingMarketDataService are unnecessarily restricted to polling connectivity. The PollingTradeService methods can actually easily be satisfied using websockets (or FIX) [apart from asynchronous return values], and frequently I would like to provide a MarketDataService and TradeService for a websockets based XChange.

Connectivity methods are becoming more varied between exchanges and sometimes it would be nice to implement an exchange using a combination of various methods, e.g. websocket for market data, execution through market data but poll open orders or similar.

[timmolter]

Another one: I was also thinking about renaming the timestamp variable to serverTimestamp to make it more obvious. Also add a note about it in the README file.

[rafalkrupinski]

@jheusser I'm not sure if I understand your issue with the polling interfaces. We can use exchange's request/response or publish/subscribe interfaces, each style has dedicated set of xchange interfaces - polling or streaming. Am I missing something? Are you talking about emulating one with another?

[supraniti]

How about FIX API support for okcoin & huobi market & trades

[douggie]

Exchange simulator and or mocking to test offline

[douggie]

Generic instrument support. Currently things are assumed to be currency pairs. More derivatives and comming into the exchanges with additional params. Maybe we should have a generic instrument class that has a type of say currency,future,swap etc, and a given type has a defined set of fields,and each exchange can be passed the type of instrument.

[douggie]

Generic protocol support-current majority of exchanges are json based,some have fix. Over time I expect things like binary protocols to minimise the marshalling,such as blaze or fast over fix. May be we should have a standard connection interface and different connection implementations can be written as they come on line. For now we have fix and json.

[radumiron]

@douggie , there is a request to an Exchange simulator which is under development, see #747

[rafalkrupinski]

@timmolter about timestamp vs serverTimestamp: you want to break compatibility just to add some information (improve descriptiveness). Why not just add or update javadocs?

[timmolter]

@rafalkrupinski That's definitely a valid argument, and I see where you're coming from. With a major version change there will be some API breaking changes anyway. Variable names should be named as descriptively as possible.

[rafalkrupinski]

Ad 4 Remove deprecated code what is it? PollingTradeService.getTradeHistory(Object...) ? BasePollingService.getExchangeSymbols() ? Anything else?

[timmolter]

@rafalkrupinski I don't understand what you're asking. Please clarify.

[baffo32]

hitbtc streaming api

[belerweb]

getTopAsks & xchange getTopBids

[evdubs]

Is 4.0 intended to be the next release? Have there been enough features added to warrant a 3.2 release while the 4.0 features are sorted out?

[mmazi]

I suggest a 3.x final release. Can we do this?

It's been a while since the last final release and I'd feel a bit better if I could use a fixed final version of the code when I need to use some of the features added in the last 8 months.

[timmolter]

OK, I'll put some work into it thgis weekend. I might just release 4.0.0, as I think most of the features are implemented and if not hopefully I can do them quickly enough.

[crypto-sporidium]

I agree with @jheusser, We need to probably re work the service interfaces so they are as generic as possible and independent of the underlying implementation, be it Poling, WebSocket or what ever may be available on some more advanced exchanges. So for example in the Exchange interface instead of getPolingTradeService, we want to have something like getExchagneServiceInstance(ExchangeSpecifications) in the beginning most exchanges would just be returning something that wraps and extends a PolingService implementation but in future when its supported you might get a websocket implementation back or what ever, The key here is really getting every thing we need in that interface.

[baffo32]

@abelgo see also e.g. #1101 . I spent some time planning precisely out how to generalize xchange so as to allow all exchanges to use the same interface and enumerate available functionality, flexible enough to allow adapters between polling and streaming interfaces allowing services to be used in either way. I think I left this work at https://github.com/baffo32/XChange/tree/refactor . I'm afraid I am not available to work on this further at this time, although I would love to finish it for pay. Generalizing these things would allow very powerful bots to be written that would really help stabilize the bitcoin market, and the profit created from the activity to be spread much more widely.