I think they should also "can" Active X and go to a pair of DLL's. One for the account, one for data. --- In twsapi@y..., "marinindextrader" <marinindextrader@y...> wrote: I completley second this suggestion. I am astounded at how difficult they have made this...perhaps complex is a better word.
Programming is intrinsically easy...the difficulty and complexity
seem to arise out of all the bandaids that need to be applied to
handle the what if's
I dont understand how the API would be difficult to program. IMHO
they need to enable direct server connections, for data, and as many accounts as one wants to attach to.
Then for the accounts it seems like a piece of cake to devise, and
build to a standard...
I am really at a loss as to how explain the present state of affairs.
Scott
--- In twsapi@y..., "Kent Rollins" <kentr@m...> wrote:
I maintain that the best solution would be to get TWS out of the loop
completely. IB should create a socket interface on their servers that we
can connect to from ours. Having TWS implement all these
different interfaces is poor design and they obviously aren't staffed for it. If they
are bringing in ONE more programmer to dedicate to the TWS API's, we can
expect more difficulties in the short term.
Kent
----- Original Message -----
From: "grozzie2" <grozzie2@y...>
To: <twsapi@y...>
Sent: Thursday, July 25, 2002 3:18 AM
Subject: twsapi: Re: Event driven garbage
Let?s assume that the portfolio event once will have a bug: It reports the
position 1 all the time.
If you want to be flat in that position, you application will sell.
Than your application will think one minute later, that it has
to sell
again, and so on.
So after an hour, your application sold 60 contracts, you are in reality
short 60 and your application just wanted to have no position
and the API is
still showing long 1 position. I am aware of this type of consequence, and it's the 'tuff one' to
deal with, but, it has to be dealt with. Your comments on error
messages etc are valid, if you are working with the
assumption 'end user is within ear shot of the computer, and can come correct a
problem'. That's not always a valid assumption, and in our case,
it's a design specification (customer driven) that we assume no
operator at the computer, so, programs must 'handle every
scenario'. So, we make philosophical decisions, and then place limits
on 'just how far it'll go'. Your situation described above, shows the
limit of 'assume the broker is right', but then look at the flip side.
Your program does 500 trades thru the day, and it's now sitting
between trades, and 'thinks' its flat. One of the trades from 4
hours ago is now broken, and suddenly the broker starts
reporting 'you are short', and the market is ramping to the
upside. Since I have no way of simulating a broken trade, I have NO CLUE
how tws will report that, and the documentation certainly doesn't
tell us
what messages will arrive at what callbacks to inform of a broken
trade. In this scenario, it's best to 'get flat', and then alert the
correct people in whatever manner is prescribed. I guess tho, this says it all. In the event of a change in position 'out of the blue',
it's a sad statement, when we have to sit here and ponder, geee,
is this a broken trade, or just another idiosyncracy of TWS ?
There will ALWAYS be situations that come up, that a program just
cannot resolve. The key to these situations, is document what
will happen, and make sure it's the 'least risk' method of handling
a 'totally bad situation'. Defining the 'desired action' is
definitely somewhat unique to each deployment. In the above
scenario, you prefer to get a notification, and deal with it
manually. My customer prefers to 'get flat, deal with it after
the fact'. The scary part is, i'm actually starting to believe, in
the event of a discrepancy, it's more likely to be a TWS error than
it is
to be 'real'.
In it's current form, IB interface is unsuitable for unattended
operations. TWS just has to many 'issues' when it comes to the
concepts of real time and process control. This was actually a real disappointment when we started working with this stuff, because we
have implentations on other brokers that function fine in totally
unattended modes of operation. All implementations have failure
modes, but every other system i've worked with, the failure modes are
identifiable, and software can make 'intelligent' choices for
handling failure modes. TWS doesn't even let a client application
know when it loses it's connection to IB, its just another one of the
things a client applicaton has to 'guess' about.
In our shop, real time process control is the 'real business'. We
view trading as just another 'mission critical real time process'
that needs to be controlled. It's the nature of the beast, most
folks that want this kind of software, want it on windows, for a
lot of reasons. When I first looked at TWS, I thought I saw a
wonderful chance to take trading off windows, and deploy it on a robust failure
tolerant environment. There's a few little things about TWS that are
going to prevent that, but, it's not a big deal anymore, simply
because a system is only as strong as the weakest link. Moving
the trading onto a redundant *nix based host wont make much
difference, when all the failure modes occur from TWS itself :(
To unsubscribe from this group, send an email to:
twsapi-unsubscribe@y...
Your use of Yahoo! Groups is subject to
|
