Decktop API Not Ready for Prime Time!

[efslooker]

I'm having a hard time understanding how esignal feels the value of the Desktop API is enough to charge for. My understanding of a API is it allows you to have a useful subset of another programs functionality without having to reinvent the wheel. Problem is the Desktop API is like renting a car with 4 flat tires, sure it will get you there but it wont be very enjoyable and it will be very very sloooow.

I'm writing a application that uses Time and Sales data. It requires me to collect ALL the data throughout the day. Seems simple enough don't you think? Well in a perfect world it would be. But in the Esignal.Desktop.API world I have to deal with System Call Failures () whenever Esignal becomes to busy. Just so you know its not my Code the TSsample does the exact same thing. In fact I built upon it for my application. Ok so now I know I must not rely on a reliable data stream. That means I need to store the data in a database for picking up where I left off. esignal.GetNumTimeSalesBars(lTsHandle) does not produce consistent results, so I have no reliable reference point. So now I have to look at a way to compare the last few records I have collected in my database and some how estimate how far back that would be from the current moment in time. And since T&S are not unique and can have duplicates, this makes it a rough estimate. Ok so for argument sake lets say, I have matched it up and I initiate the Tick request, here's the really cool part. The T&S comes in at roughly 14 min of data per 60 seconds. So if you were behind the market say 3 hours that would take approximately 12 min to download this information or 1/2 hour for a full days worth. Am I back in the modem days again? Please! Compare that to the few seconds it takes Esignal to pull in T&S on their own T&S charts. It seems to me Esignal would give you the necessary features to download reliably at the minimum and to pick up where you left off. Because every time I have to re-request non current data, that has to be putting a load on the server.

I was told this would be a good option for someone who wanted to develop a program and then to step up to the standard API if it is worth pursuing. I suspect I am having to write more code wasting more time trying to deal with this products inadequacies. From reading the posts I know you Esignal guys take a certain amount of pride in this stuff and normally I would not have said a thing, but in this case I just had to say something. I'm mostly disappointed Esignal charges for something that does not deliver.

If you agree with me please chime in, if you think I am wrong please correct me. I would love to find out that it is just my ignorance about the whole API and that these things I speak of really are possible. But I'm not holding my breath, I almost passed out last time I tried when I was 4.

Regards,

[Guest]

Let me try to respond to this . . .

We had some problems with certain combinations of calls to GetTimeAndSales(), which have been addressed in 7.8 (released today) with the help of some developers on this forum. Time and Sales are currently retrieved individually and we are looking to add a function so that it returns an array of data. Time and Sales is tick-by-tick level information, which equates to many calls and a lot of data, however I do know of some (relatively strong) developers that have had success obtaining T&S data and the product has worked for them.

The Desktop API is an interface to eSignal, which in turn communicates to our server farm, to give you an idea of the data flow. It is priced relatively low, geared towards retail use (although there are commercial deployments) and works extremely well for certain application scenarios, but has never been announced as our most powerful and robust solution for "programmatic" data.

Our Standard API product is only available for commercial development and communicates directly to our server farm. We obviously need to be very careful on how data is accessed on our farm, so we have engineers involved in both the pre-sales and application certification process. This product is also significantly more expensive, but if you are meet the requirements and are interested, you can fill out the Enterprise Solutions Form in our Institutional Investor page.

[HeiDie]

Hello Robi,

have you ever read the marketing material about the Desktop API on your web site? It is very very misleading, generates high expectations that are by far not fulfilled by the actual product. And it is expensive. Not only do we pay the bucks for the use of the API, there are also the cost of all other eSignal modules that add up. I for myself am still not able to simply get the data to build an actual daily bar (Open, Day High, Day Low, Realtime Price) for the 500 symbols I subscribed to. Any idea how to achieve this? I would be happy to get these data in a simple procedural form like getdata(in:SymbolsArray, return: OpenArray, HighArray, LowArray, LastpriceArray, TimeOfLastPriceArray), even if I have to request it in chunks. Then I could easily manage the data on my side. Right now, with the events and system instability / unreliability, I never really know which data I still have to wait for and if they ever come.

After that piece of critique, I want to comment you on the achievements made since you, Robi, are on board. Maybe, you work with product management on some restructuring of the API. On one hand, the controls to the eSignal GUI. I very much like the control I have over Advanced Charting from my little application to quickly go through the charts of all kind of symbol lists I get from my scanners. On the other hand, the data feed. According to all the arguments in the API forums, you need to think about restructuring it. Maybe you call out a forum for discussing how that should look like. Would be something different and forward looking than all this complaining. And it would make us, the users, feel good about being able to participate in the future of the product.

Thanks for listening
HeiDie

[JimBecker17]

Reply regarding T&S data.

When fetching records from the eSignal servers to winsig this is "fast enough" to back fill old records on most symbols.

I don't understand the "14 min in 60 sec". On average might be five seconds to fetch a days of standard data to winsig, and then about 5000 records per 3 sec on a 2.8Ghz machine across the link.

One DISCOVERY though which might be bugging you is a 2 second delay on this fetch PER-Window you have open in your layout. This took a while to track down. Try getting T&S with a fully empty eSignal MDI window and see what happens.

It seems eSignal is also servicing those windows quite often, and since you make a lotta calls the additional overhead really builds.

The major delay is moving the records from winsig into ones application - as they are one at a time. Also one has to wait until record collection has "settled" to determine backfill is complete.

It sounds like you are getting records and are getting backfilled at the same time. Yes, kind of odd design but once you figure it out it works. Just wait until backfill completes before starting.

Also you might try absolute indexing of the array.

Robi and Co. are aware of the need for array transfer, and I'm under the impression it will happen.

The API potentially could be better designed, but everyone has an opinion of what is better. How it stands one can get their data and convert it to your needs with what is provided. If you need a lot of symbols all the time also blend in DDE logic going to winros rather than through the extra layers.

-Jim Becker

[Guest]

Isn't marketing is supposed to provide high expectations? You should have seen some of the products I was developing in the .com days.

I will say the API will NOT be redesigned. It was designed to be a Honda Civic and works well as an economical API for market data. Unfortunately, some people think they bought a Porsche.

I am the product manager the API and am fighting to have some features added (like the one Jim mentioned), but my focus in the past few months was to find some of the hard-to-capture defects. I do appreciate the comments and am working on making the API more robust with additional features.

As far as building daily data, that really shouldn't be extremely difficult. On an intraday basis, I would ask for 5 minute intervals so all of responses are handled, rather than on a tick-by-tick basis. I did something very similiar to what you are trying to do about a year ago with this API. On an end-of-day basis, there is an example in the file share that does this for 100 symbols. For 500, I would do it in batches.

Jim, thanks again for contributing with your expertise - it's always much appreciated.