PureBytes Links
Trading Reference Links
|
This is an Industry Standard, OPEN platform ?
I am trying to tie to my existing online, realtime broker....that's all.
> -----Original Message-----
> From: Charles Kaucher [mailto:steinbr@xxxxxxxxxxxx]
> Sent: Wednesday, November 24, 1999 2:27 PM
> To: M. Simms
> Subject: Re: CL_RE: Rollover workarounds for TS?
>
>
> OK Does anyone have the API and would be willing to share it?
>
> At 10:28 AM 11/24/99 -0500, you 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
>
|