" a packet sniffer " ... He he....I dont know why this made me laugh
but it did....
Scott
--- In twsapi@y..., realquotes101 <no_reply@y...> wrote:
Hi,
I think this is a great idea, but whether they would
allow "uncertified" programs to directly interact with their
servers
is unclear. The current socket interface (in the API) is only
there
as a stripped down way to control the TWS, and would likely have to
be redesigned.
If IB ultimately is unwilling to provide a direct interface.
There is another solution that is even more global. Replicate the
function of the TWS, and then create our own program/API. Since IB
apparently uses FIX, a packet sniffer may be all that is necessary
to
get the info to implement this. Not a small project though...
Andy M.
--- 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
