Support Board
Date/Time: Sat, 23 Nov 2024 06:53:58 +0000
Post From: Announcement: Open Specification Protocol for Connectivity to Data and Trading Services
| [2013-06-16 22:33:08] |
| |
|
We see this differently. The most important thing is that service Data and Trading service providers adopt this. That is going to be the biggest hurdle. They are not going to have any problem working at the protocol level and providing a library is not going to change things. If we were to provide a library, that only introduces a whole another aspect which would be outside the scope of this initiative which is only going to create undue interference with getting this protocol adopted. For example, do you think DTN would be more interested in adopting is protocol if there is a library for it? We would think that would not even be relevant at all, and if we were the ones creating a library, they would then have more of an incentive to stay away from this because they would probably disagree with how the library works. When it comes to actual implementation in a particular language, everyone has their own view on how that should be done. And that is the primary complaint about API components. They are too proprietary and specific to a particular implementers view of how to program. We can tell you, there is a lot of junk programming out there. If libraries are created, then that will be the responsibility of implementers of this protocol. That's not for us to be getting involved with. At some point, will be contributing a C++ wrapper class that supports the protocol to simplify the use of it. One popular library for fix is quick fix. The C++ version, is substandard. We did use it for a while and it was a waste of time and created problems. We implemented our own FIX processing class which is vastly superior. Quick fix is heavyweight, overly complex, hard to use, terribly inefficient, and has bugs. We have seen similar comments about it from other programmers as well. It drops messages and disconnects without giving any reason. It has everything that we simply do not like. Take for example Tele-trader. They had contacted us and were interested in us adding support for their data services. We did begin some work with the integration. For real-time data the only choices for integration are an API component, which we stay away from, and a web-based protocol which is more complicated than we are comfortable with and is an older protocol. So the fact that they actually have a library, is a disincentive for us to even work with them. Everyone has their own view. 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-06-16 23:08:27
|