|
PureBytes Links
Trading Reference Links
|
Very interesting reply.
Is there a similar explanation as to why Tradestation is not open for
development of for example an add on for backtesting with optimisation over
many stocks? That API is also very limited.
> -----Original Message-----
> From: M. Simms [mailto:prosys@xxxxxxxxxxxxxxxx]
> Sent: Wednesday, November 24, 1999 4:29 PM
> To: Omega List; Larry Wright
> Cc: Code List
> Subject: RE: Rollover workarounds for TS?
>
>
> 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
> >
>
|