Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Fri, 26 Apr 2024 03:09:44 +0000
Post From: Mirus/Zenfire: now with server-side OCO and bracket orders
| [2013-12-27 05:26:19] |
| |
|
We had no contact with big tick developers. We only have some indirect familiarity with the new Zen-fire system. The final management decision at this time, is we will not be supporting the Zen-fire in process API component for trading or market data. It was a mistake to have spent time on the trading support. It is firmly against our policy to work with API components. We considered an exception to accommodate the existing users and proceeded along with the exception by doing integration work until we were reminded why we have this policy after working with the Zen fire API. There are not many Sierra Chart Zen fire users overall. At this point, it is up to Zen-Fire to support FIX or DTC which may come at some point in the future. This is what we hope for. We have communicated our position to the Zen-Fire management. This decision is ours, and it should not be taken negatively towards Zen fire in any way. Although it is no secret, that we do not like API components, to put it kindly, and think they need to go. We will be supporting the Zen fire API, to verify user has a trading account, so they can take advantage of the CME exchange fee waiver and use the Sierra Chart market data feed. More details will follow. Another very basic reason for not supporting the API, is that supporting a new trading service ( effectively the case with this new API) is a very significant programming task. In our experience it takes about one year to perfect integration . We have many other higher development priorities and we need to serve the interests of the vast majority of our other users. This is where our obligations are. If a particular backend trading platform, drastically changes their interface, and to something which is not within our policy to support, this is not our problem. Once again, this decision should not be considered negatively towards Zen-Fire or Mirus. This is simply the situation that has arisen, which is the fault of no one. By deciding not to support API components, has only been a great leap forward in this industry and for Sierra Chart. Sierra Chart is much more stable and better designed and we are really seeing the benefits of a whole new interfacing model. The more, we consider this whole concept of API components, the more we realize, just how it makes no sense. This is coming from very competent intelligent developers. The idea of forcing upon another developer, a particular programming model is not neutral. There must be a neutral communications protocol that exist between two parties. This has to be a binary/text protocol with at least some element of relationship to the well-established FIX protocol. It does not necessarily have to be FIX. API components to data and trading services, are not some simple kind of passive (not sure using the correct terminology here) libraries like a XML parser which are open source. Instead these APIs are very complex multithreaded active blackbox components where we have no idea what goes on within them internally or properly understand how they work. And furthermore, we are not afraid in the least, to be criticized very strongly by the firms that use these API components as to our position. And we understand why they use API components to begin with. It is perfectly fine to use an API component, if it is open source and there is an open low-level communication protocol that the API is built on top of. For example, they can build on top of DTC. DTC even has consideration of obtaining the ID of a machine in the logon message. It provides everything that a firm would require. There are two areas where DTC need some improvement and that is converting all of the quantity types to doubles. This is in progress now. And supporting variable length strings. We are going to be working on that in January. However, the way strings are handled now as fixed length is perfectly acceptable for most cases and easier-to-use. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2013-12-27 20:42:05
|