开云体育

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

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

" 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

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

} 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.
}

I've heard some folks have decompiled the TWS and modified the code
themselves -- long before the API became available.


Richard

I've heard some folks have decompiled the TWS and modified the code
themselves -- long before the API became available.

The reason I kind of like an api into TWS, it bypasses all the
hassles of logins etc. A raw socket api on the server end, is going
to introduce a security layer.

With that said, there are a couple of things I'd like to see in TWS
itself, to accomodate fully external driven environments. First off,
would be great if it didn't pop up that 'do you wanna let this
connection happen' dialog, and it would be even better, if we could
run it in a 'dont even draw any windows' mode, to allow it to be run
on a totally headless system, that has no monitor, no keyboard, and
no video subsystems even loaded, aka a remote *nix setup.

Security is a non-issue with sockets. Every packet that comes in is
validated and processed by the server application. If the API and socket
data structures don't include commands to do things like delete files on the
servers or download information that is not directly available in the
specified API, the client cannot command the server to do it. The client
can only command the server to perform specific actions that are defined by
the API. Very simple. The only concern would be someone obtaining the
user/password but then that is always a risk with external logins.

As for the single login thing, that would certainly be a concern for some.
Perhaps a rules adjustment would be in order to allow for this scenario.

Kent