Curious if there is any interest to support CQG. IMHO, CQG is the Creme’ De’ La’ Creme’, and is supported by many firms and bank clearing operations for client accounts. Additionally, some of the best data (historical and real-time) can obtained thru their systems, as well as order routing, position management. It is like IB, in functionality, but you can open an account with any CQG supported firms, banks, brokerages; you just let the CQG api, account login simply ties to your account etc. CQG’s continuum client product come to mind.
You could have other real-time vendors, but not be subject to duplicate exchange fees either.
I wrote CQG plugin some time ago (in 2009) and it was working fine.
But… few months later CQG changed their API to something that is completely different, not backward compatible.
Sorry, but I can’t work that way. I need stable API, not something that changes upside down every few months. I develop data plugins for free. And since I don’t earn any money on plugins I want to write it ONCE as time resources are really limited.
For what it is worth: I gave CQG full sources to the old plugin. For free. But they were apparently not interested in working on it either.
Perhaps if you gave it out to us, we might fix it to work. Even if someone doesn’t, it would be great to see how you wrote it and use it as a template to follow for your users in writing their own plug-in’s etc. Food for thought.
I understand what you mean, but sometimes just because they turned it upside down doesn’t mean necessarily they will be in the habit of doing so again.
I would gladly give the sources to you - but… CQG API is closed and with CQG API you are bounded by CQG’s NDA (non-disclosure agreement). Since CQG plugin contains calls to CQG API which is covered by NDA it essentially means that everyone who would like to see that would need to sign CQG NDA.
It is the same with every corporation that has too many lawyers and why I am “not so enthusiastic” about closed APIs.
I would love to look at your plug-in, primarily to see it as a template.
CQG’s API, come in different flavors…
1.) WEB API
No CQG Continuum Client application install on a the computer needed.
Data, real-time, historical and trade routing.
2.) Integrated / continuum Client API
Integrated / Continuum client application installation needed.
API connects to application via COM object
Data real-time, not sure about historical
Might be able to call functionality of software suite on machine like charting
3.) CM API
New, not sure.
I’m going to take a deep dive into the CQG’s Web API, should be very straight forward.
The plugin used Continuum Client API which was (afair) the only available back in 2008/2009. WEB APIs tend to be slow, esp. for RT streaming.
I had three second look at their WebAPI examples and it looks like typical “we have too many developers who need to prove that their position is really needed so let’s produce tons of bloat” (2.8MB of JScript source codes??? That is ridiculous! Old AmiBroker’s CQG plugin C++ source codes are 84kB (kilobytes), but we don’t have hordes of people here)
Another point to consider would be the fact that CQG has been positioned on the high-end of the market and could bring along audience whom might appreciate this level of servise.
As you have pointed out this may mean more work for Amibroker Team but also may potentially be positive for the bottom line of the brand. As they say “there is no gain without pain”.
IMHO, High end == expensive bloat
Agreed, definitely overpriced.
According to my humble opinion, I believe in no right or wrong in life, but balance. This of course not a belief system on its own but could make sense when considered with other supporting beliefs.
What might be overpriced for one, could be affordable for others.
Hence, it is up to each individual to conduct the risk management to avoid blowing out (in trading or in any other business) and sustain balance. Where balance prevails there is no overpriced or under-priced service but only the service one could attain without any stretch or degradation.
ESignal has a plugin eSignal futures trader, that connects to CQG. Maybe that is an alternative route to avoid duplicate exchange fees. You have to use one of eSignals listed brokers, I use Macquarie here in Australia. Works fine for me but auto trading from Amibroker not an option.
My name is Doug Janson and I work for CQG - I was the person instrumental in getting the CQG data feed C++ plugin working with Tomasz and AB. His recolection of events is correct… however i didn’t know that our Java API had alot of bloat.
I still have a number of CQG customers that I direct to AB for high end testing needs. Unfortunately they have to use IQfeed into AB and rely on CQG data for the automation of the trading. This can lead into problems when the back adjusted data is off between the two data feeds.
If there is someone willing to take a shot at getting the C++ code working - or running it though our API I am sure i can get the approvals for anything that might be locked down on the CQG side. I am interested in a solution for my self and a handful of customers using CQG data in AB.
If I remember - the one limitation with the C++ plugin at the time it was developed was that it didn’t pull in continuation data, only month specific which of course will limit many research needs.
I think the proper way to approach this would be through Continuum’s API. Also the resulting module should be open source.
You can contact me at firstname.lastname@example.org and I will do the footwork within CQG to get it started.
I am sorry Doug if you felt bad about my "bloat" statement, but I have different standards than industry. I started programming with Z80 CPU when 2KB of ROM was quite large space for writing programs. I remember I wrote entire OS in 1.5KB (in assembly of course). Today AmiBroker executable is 2.2MB plus 2.9MB all DLL libraries required. It is smaller than help file. So by my standards any software above 10MB is bloated, and by these standards 99% of software is too big.
Discourse (the forum software we are using here) is very bloated IMHO, but still, it works. In fact given its sheer size I am surprised it works really well. So maybe I am just outdated
Refreshingly nice view Tomasz Thanks.
oky, when I understand right there ist no possibillity for getting CQG RT data into Amibroker?
Did anything come of this discussion? Any possibility of a CQG data feed into Amibroker?
Recalling the topic in 2019.
Really hoping @Tomasz to bring back CQG support.
Would open the door to many traders to getting affordable & reliable realtime data into Amibroker
After CQG plugin was developed, CQG changed their API completely breaking it.. They need to stabilise API and make sure that future updates don't break existing software, then somebody may be willing to spend time on their API.
If I could share my opinion. While they could have re-vamped their API and left some sort of legacy compatibility, I would say with the help of new tech and bandwidth I think everyone is certainly welcome at at least one shot of re-writing their interface API. That said, there are now many firms/banks and third party providers linked up with CQG for data and order processing, where I think they are less inclined to do this sort of thing again IMHO.
Also with Schwab and TD Ameritrade possibly merging, the TD API looks nice also.
I think if you were to open up your finest highest performing API to date, users can retrofit the endpoints for whatever platform.
Dunno, just an idea.
I was a customer of AB for many years, maybe ten or more and I was still subscribed to this old thread.
I quit use AB due to lack of CQG or Rithmic datafeed moving to an other sw that I liked less!
I still love AB and I really hope that it will survive in the years adding support to most known datafeeds and a ready-to-go chart trading interface. I wrote this to TJ in a mail many many years ago but it seems it didn't solve
All the best to all AB community!