You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Comments on eSignal 7.x and above
- Thread starter Chuck_T
- Start date
JayF_eSignal
eSignal
juggernaut,
Your information about our API is incorrect. With the RequestHistory Function you can request any number of bars or days of data. Please see page 4-5 of the Desktop API documentation for further details.
Regarding the fees associated with the API, there was a definite cost for development of the API and supporting it going forward. In order to not affect the monthly rates of users who don't plan on using this feature, we decided to market this as an add-on feature with associated one-time and monthly fees.
Your information about our API is incorrect. With the RequestHistory Function you can request any number of bars or days of data. Please see page 4-5 of the Desktop API documentation for further details.
Regarding the fees associated with the API, there was a definite cost for development of the API and supporting it going forward. In order to not affect the monthly rates of users who don't plan on using this feature, we decided to market this as an add-on feature with associated one-time and monthly fees.
Quote from JayF_eSignal:
juggernaut,
Your information about our API is incorrect. With the RequestHistory Function you can request any number of bars or days of data. Please see page 4-5 of the Desktop API documentation for further details.
Regarding the fees associated with the API, there was a definite cost for development of the API and supporting it going forward. In order to not affect the monthly rates of users who don't plan on using this feature, we decided to market this as an add-on feature with associated one-time and monthly fees.
JayF
Thanks for the reply, but I looked at the API. A request
takes one call but getting a bar back from esignal takes
another call. So 40000 tick bars will take 40001 calls.
Arrays were invented for a reason.
Esignal can charge what it wants but discriminating against
small developers is what bothers me. Commercial developers
and users of commercial packages get the real interface with
no charge. While small developers and users of such software
get a stunted interface and have to pay for it on top of it.
Anyway just suggesting you make the API a little more useful
and you may get more subscribers.
Thanks,
Juggernaut
JayF_eSignal
eSignal
Juggernaut,
First off, I appreciate your comments about the API and pricing. We try to welcome as much feedback as possible, as it is with this that we can improve our service, our business and ourselves.
Just to clarify our standing on pricing, we are not trying to discourage the non-commercial developer from using our API, but instead are encouraging commercial developers to use our API by providing a price break to return the favor, so to speak, of bringing in additional business. I agree with you in that by lowering our prices, we would be bringing in more API business. At the same time, this would also increase the cost of supporting the API (a high-end, high-cost support.) In looking at our pricing models, we found that under the current market conditions, this is the pricing structure we can go with. Going forward, market conditions will change and we will revisit the pricing from there. Recently, such an event took place with the elimination of our Regional Fees, lowering of Market Depth fees, and combining the eSignal Equities and eSignal Futures products into eSignal Premier.
On the API issue, my apologies for the confusion. You are correct that once the handle is created with RequestHistory, that the GetBar function in needed to be called repeatedly in order to fill the entire request.
First off, I appreciate your comments about the API and pricing. We try to welcome as much feedback as possible, as it is with this that we can improve our service, our business and ourselves.
Just to clarify our standing on pricing, we are not trying to discourage the non-commercial developer from using our API, but instead are encouraging commercial developers to use our API by providing a price break to return the favor, so to speak, of bringing in additional business. I agree with you in that by lowering our prices, we would be bringing in more API business. At the same time, this would also increase the cost of supporting the API (a high-end, high-cost support.) In looking at our pricing models, we found that under the current market conditions, this is the pricing structure we can go with. Going forward, market conditions will change and we will revisit the pricing from there. Recently, such an event took place with the elimination of our Regional Fees, lowering of Market Depth fees, and combining the eSignal Equities and eSignal Futures products into eSignal Premier.
On the API issue, my apologies for the confusion. You are correct that once the handle is created with RequestHistory, that the GetBar function in needed to be called repeatedly in order to fill the entire request.
Quote from corvus:
The ActiveX API does not stream prices?
An event is triggered that tells you that the array of bars has changed. You then call a method to determine what the change was and a function to get the data. In very rough pseudo-code, here is an example of an event handler you might write.
Code:
myOnBarChangedEvent(symbolHandle)
{
count = esignal.GetBarCount(symbolHandle)
for x = (-count + 1) to 0
processBar(x, esignal.GetBar(symbolHandle, x))
endfor
}Things to note, the most recent bar in time is always at index zero. While this allows for dynamic backfill (my guess as to why they do it this way?), I don't much care for it. In my opinion they should be using absolute indices. If I ask for bar 0 ten times in a row, I want to know that I am asking for the same bar each time. One problem is what if I am looping through all the bars to get the data and a new bar comes in during the middle of my loop? Esignal would shift all the indexes down one and I would end up missing a bar of data in my processing. Who knows, maybe they provide some sort of lock during event processing, but I wouldn't assume it.
Quote from juggernaut:
A request
takes one call but getting a bar back from esignal takes
another call. So 40000 tick bars will take 40001 calls.
Arrays were invented for a reason.
Most definitely. This isn't so much of a problem (for me) with daily or minute bars, since I only process a few hundred to thousand at most at a time of those. The problem is if your app needs to load time and sales data for the day on something like the ES which can easily produce 300,000 ticks in a day (including bid/ask changes). Due to the current requirements of needing to call an ActiveX function to receive one tick at a time, if my app needs to be restarted late in the day and load those ticks again, I have to sit for minutes, not seconds, before everything is functional again (I load data for both ES and NQ). There really really needs to be a function that says here is my buffer which is big enough to hold all the ticks, please fill it using a very efficient memcpy in one swoop.
BTW, the minutes of waiting is not spent waiting for the data to come down from the esignal servers. The data is already cached by esignals data manager (in the event of the app restart I mention). Even grabbing the data from the servers is extremely quick to reach the data manager. The delay is most definitely in the method required to retrieve the ticks one "expensive" function call at a time.
BTW, I just want to let everyone know that I am happy that eSignal has chosen to release an end-user API. It isn't perfect yet, but it is a very good start and if they listen and consider and implement (the good) suggestions from all the developer input the receive, it can only get better. Just don't want folks to think I am just pointing out the flaws of the API (as I see them).
Does eSignal plan to lower their CME fees on Jan 1st 2004 like Qcharts ? (CME will go down from 53$ to 33$)
http://finance.lycos.com/qc/subs/rtfees.aspx
http://finance.lycos.com/qc/subs/rtfees.aspx