This is a tricky question. On the one hand I can see your point Kent.
Having a pure programmatical socket interface would avoid the UI
issues inherent with a rapidly evolving TWS. Developers using both
low level and high level programming languages could be equally happy
with such an implementation. It would give programmers much more
control over the whole process.
On the other hand what happens to someone who wants to run their
trading interface and see the TWS updating their market positions
simultaneously? IB currently prohibits more than one connection per
account. How could they retain the security of a single connection
while at the same time providing ability to interface directly and
also synch the updates in the TWS? I'm sure many (most) would like
the benefit of seeing (verifying) their trade results in the TWS as
well as through the programmatic interface. I wonder what other
security issues might arise by having 3rd party programs interface
directly to place orders?
--- In twsapi@y..., "Kent Rollins" <kentr@m...> wrote:
I'm not only thinking of myself when I suggest that separating the
different
API's would be a better solution. I have been programming
professionally
for 15 years so I know a little bit about how the different
missions of TWS
cause complexity in the software to rise not arithmetically, but
exponentially. Plus there is the fact that as IB goes to make
improvements
to the user interface of TWS, people who have MISSION CRITICAL
applications
(read again: that's MISSION CRITICAL applications) are subject to
more
rounds of debugging even though their interface to the application
has not
changed.
My only suggestion is that they put a socket interface on their
servers and
get TWS out of the loop for people who are only interested in
programmable
interfaces for trading. Once a socket interface is established, an
ActiveX
wrapper and a DDE wrapper could be put on top of that programmable
interface
and it would be MUCH easier for IB to upgrade the socket interface
separately from TWS and vice versa. This way, everytime IB makes
changes to
TWS, they don't have to worry about breaking the socket or DDE
interfaces or
any of the kludges that we have written to "work around" TWS's
current
idiosyncracies. Easier for them. Easier and more importantly MORE
STABLE
for us.
I don't know all the details of the socket interface, but it sounds
fairly
complete as is, therefore it is subject to less change going forward
especially if it were separated from TWS. In contrast, TWS is a
user
interface. In user interfaces, change is the only constant. This
is the
way it always is in software. API's are intended to be stable.
User
interfaces are always subject to upgrades. If you're a programmer,
you know
this.
I would support a group effort to request and support IB in
separating the
socket interface from TWS. If we make this request of IB, we
should do it
quickly because they are about to hire someone to fix the socket
interface
on TWS. I suggest that those efforts would be better spent
replicating the
current socket interface from TWS to their servers.
Kent
----- Original Message -----
From: "Marcus Jellinghaus" <Marcus_Jellinghaus@G...>
To: <twsapi@y...>
Sent: Saturday, July 27, 2002 2:22 AM
Subject: AW: twsapi: Java Events-- avoinding the API
<snip>
Kent Rollins posted:
IB has taken a difficult route in making this one app into a User
interface,
an ActiveX interface, and a socket interface. Separate
apps/libraries
would
have been a better way to go.
What is the your opinion?
Is it a really necessary? Would a solution with the current API be
a "too
big work around"? Couldn?t you find a good solution?
Do you think that IB could fix it without rewriting the whole API?
Than we, as the list with 517 members should ask IB to improve it.
Perhaps
they listen to us.
Marcus
