-
Notifications
You must be signed in to change notification settings - Fork 2k
Conversation
Wouldn't it be better to add a generic plugin interface to engine.js than hardwire the xmpp protocol into it. There are a lot of messaging apps out there, and everyone have thir own preferences. WebSockets comes to mind for building a messaging interface. It opens the possibility for all kinds of extensions |
Completely right. I will look into abstracting the messaging protocol and controlling the bot through (xmpp) messaging. Those are my first steps with node.js and I was amazed on how easy it was to integrate xmpp. Any other coding challenge is beyond my capacity for the moment. |
The topic is interesting, and I have some ideas around this to share. My nick on Discord is tuxador if you wan to discuss. https://discord.gg/HcPhKX |
@piedrogenius |
@tuxitor I fully agree with your comments here, but I'm also a firm believer in building blocks, the existence of this will make it easier for people to start using XMPP today and future contributors to easily extend this. Merging. Thanks for the work and time @piedrogenius! 👍 |
@DeviaVir To the contrary, the zentalk concept has a lot more potential for extension without changing an additional single line if code in the engine program. This means a lot for maintainability of the code because all extended functionality is done outside the zenbot code. As of today zentalk have both mail and xmpp reporting, and have had for quite a while. Besides that zentalk has access to most of the zebot data in a form (JSON) which is ideal for use by other programs (still without the need for changing anyting zenbot) From the interactive zentalk program a lot of data is already available in JSON form. These are options, balance, product, period, strat, quote, status and trades availabe through a get request. some options are even possible to change during a live run. The period object is ideal for extracting candles, to name one. Only imagination limits the use. And still without changing anything in the zenbot code. This is modular design, and the documentation is quite decent https://github.com/tuxitor/zenbot/blob/zentalk/docs/Zentalk.md I think it is worth looking into it again. |
@tuxitor by no means am I saying that these overwrites any and all other efforts, I'm only saying I'm not principally against adding a change just because there is a better way (that hasn't been picked up by anyone so far). The ticket to implement something better is still open, for example. |
…os8f-master * 'master' of https://github.com/carlos8f/zenbot: Improve command help for train command (DeviaVir#436) Support for missing win/loss and error rate from output (DeviaVir#426) Fix docker builds for forex.analytics (DeviaVir#424) Minor fixes for Quadriga trading API (DeviaVir#421) xmpp for trading alarms (DeviaVir#333) Strategies: TA (ema+macd) and Trust/Distrust (DeviaVir#285) Fixed docker build (DeviaVir#349) updated c.default_selector to c.selector in README.md (DeviaVir#418) added check for message before doing anything with it (DeviaVir#412) FIX: Properly check for unknown indicators in forex_analytics (DeviaVir#408) Added support for the BTCe exchange (DeviaVir#388) Add strategy: forex.analytics, an genetic optimization algorithm for TA-lib stats (DeviaVir#389) # Conflicts: # .gitignore # commands/sim.js # extensions/exchanges/bittrex/exchange.js # extensions/exchanges/quadriga/exchange.js # lib/engine.js # scripts/auto_backtester/backtester.js
* use of xmpp * xmpp configs * Update conf-sample.js * Update engine.js
Added optional account set-up and buy/sell alarms with XMPP. Needs simple-xmpp and 2 XMPP server accounts: one for sending the trader messages and one for receiving them.
Considering two way functionality to disable/reenable live trading while running