PureBytes Links
Trading Reference Links
|
OK Does anyone have the API and would be willing to share it?
At 10:28 AM 11/24/99 -0500, M. Simms wrote:
>Gang -
>the answer to the issue of being able to do fancy things with the data
>server have been answered below...
>see the "attitude" in-effect at Omega.
>We are TOTALLY locked-out of doing anything related to the data
>platform.....unless you can get the highest level of approval....from "you
>know who".
>
>
>Mr. Simms,
>
>Our development contracts with existing data providers prohibits us from
>designing or providing technology for our products to interface with
>competing data platforms. Because of this, distribution of the sub-server
>API is regulated by our Corporate Development office, and they select which
>companies are granted licenses for this API.
>
>They are currently not accepting any new applicants at this time, so we
>unfortuneately, cannot accomodate your request.
>
>Kind Regards,
>
>Omega Research Inc.
>
>
>-----Original Message-----
>From: M. Simms [mailto:prosys@xxxxxxxxxxxxxxxx]
>Sent: Monday, November 22, 1999 2:02 PM
>To: orsp@xxxxxxxxxxxxxxxxx
>Subject: FW: Support for Global Server - ADVISE
>
>
>What's going on here ?
>We have a terrific idea which will interface Tradestation to a reliable,
>high-speed data feed !!!!
>It will help to sell more TS product !!!
>
>What's all of this nonsense about "current obligations" ????
>Doesn't make sense !!!
>
>
>-----Original Message-----
>From: Developer Support [mailto:DevSupport@xxxxxxxxxxxxxxxxx]
>Sent: Monday, November 22, 1999 11:15 AM
>To: prosys@xxxxxxxxxxxxxxxx
>Subject: RE: Support for Global Server - ADVISE
>
>
>Mr. Simms,
>
>Projects of the nature you have described require the use of a SubServer API
>which at this time is under the strict management of our Corporate
>Development Department. From what I understand, registered Omega Research
>Solution Providers may apply for this technology, but due to current
>obligations (contractual and otherwise), no new applicants are being
>considered to receive the API at this time.
>
>For more information about this, you can try contacting our ORSP management
>group by emailing orsp@xxxxxxxxxxxxxxxxxx
>
>Omega Research, Inc.
>
>
>> -----Original Message-----
>> From: TechSupp
>> Sent: Wednesday, November 17, 1999 4:44 PM
>> To: Developer Support
>> Subject: FW: Support for Global Server - ADVISE
>>
>>
>>
>> -----Original Message-----
>> From: M. Simms [mailto:prosys@xxxxxxxxxxxxxxxx]
>> <mailto:[mailto:prosys@xxxxxxxxxxxxxxxx]>
>> Sent: Tuesday, November 16, 1999 8:18 AM
>> To: Omega Research
>> Subject: Support for Global Server - ADVISE
>>
>> We want to write an interface to a data provider.......
>> noticed there were sparse technical notes in the DEVKIT for TS2000i
>> regarding the ability to update the server from another source.
>>
>> Where can we get the necessary sample code and more detailed documentation
>> to do this ?
>>
>
>
>> -----Original Message-----
>> From: Larry Wright [mailto:lwright@xxxxxxxxxx]
>> Sent: Tuesday, November 23, 1999 12:32 PM
>> To: Omega List
>> Subject: Re: Rollover workarounds for TS?
>>
>>
>>
>>
>> On Tue, 23 Nov 1999, Val Clancy wrote:
>>
>> > the best you can do is:
>>
>> Unfortunately, I agree with you. If this is the best one can do with
>> TS/Omega, we're in trouble. Data manipulation should NOT have to be as
>> hard as you describe! It would NOT be this hard if TS would allow easier
>> data access in/out, especially for ***tick data***.
>>
>> I forsee the Historybank as another you-will-do-it-our-way approach by
>> Omega. It will have only the most 'vanilla' data, and will not take into
>> account the *many* ways traders like to manipulate data. IMHO, a terrible
>> alternative to opening up TS *tick* data access.
>>
>> > Build your historical testing ascii database:
>> > - pick a bar interval for your database, 1 min for instance.
>>
>> This is a *lot* more work if you use tick charts...
>>
>> > - merge individual contracts manually ( cut/paste ) or use
>> fileappend for
>> > automatic
>> > operation.
>> > - when back adjusting data you can use different contract merging
>> > techniques.
>>
>> It IS very important to provide several ways to merge contracts, and very
>> unlikely to happen with Omega's you-will-do-it-our-way approach
>> to things.
>> Different traders have different needs. 'Merge contarcts' is easy to say,
>> much more work to do :-).
>>
>> > your system code could contain rollover exit / reentry signals, no
>> > backadjusting necessary
>>
>> Some of us like continuous contracts (but not all :-)...
>>
>> > in this case or you can set up "ave tick volume match" rollover fairly
>> > easily by using
>> > data1, data2, dataN setup and dumping into a file from multiple data
>> > streams.
>>
>> A good approach...
>>
>> > - keep your "SP rollover" workspace saved and ready to be used
>> at any time
>> > - if you get holes in data, write it down in your database log,
>> patch data
>> > and append it
>> > to your ascii database. same thing for bad ticks.
>>
>> With the difficulty in working with TS, this is a real pain - also, I'd
>> rather not have to maintain two (or more) different data bases and try to
>> keep them in sync and up to date.
>>
>> > - use ascii database for historical testing and real time data
>> for trading
>> > and appending
>> > to your database.
>>
>> This *still* does not leave us with an easy way to use rollover data in
>> *real time* for new contracts (a workaround has been suggested, though).
>>
>> *Please* don't misinterpret this as an attack on what you said. Don't get
>> me wrong - I really do appreciate your detailed suggestion for the best
>> way to deal with this. It is, indeed, about the best one can do now. I do
>> believe this is a major area of concern for many traders, and has been for
>> MANY years, with NO adequate response from Omega despite years of asking.
>>
>> Omega seems to stress how "easy" it is to use TS. For such a basic thing
>> as *tick* data input, output, or contract manipulation, I don't think
>> so...
>>
>> Larry
>>
Charles Kaucher
"Well done is better than well said."
-- Benjamin Franklin
|