IB API...

[Glenn H Tarbox, PhD]

I put up some summary info grabbed from eclipse to help me navigate
through what needs to be generated. It couldn't be posted on the wiki
because it looked like spam... an omen? :-)

its at: http://tarbox.org/sage/ibapisummary.txt

seems like XML-RPC could be auto-generated...

-glenn

--
Glenn H. Tarbox, PhD || 206-494-0819 || gl...@tarbox.org
"Don't worry about people stealing your ideas. If your ideas are any
good you'll have to ram them down peoples throats" -- Howard Aiken

[Brett Nakashima]

That looks quite promising.

-Brett

[Glenn H Tarbox, PhD]

I wonder if we couldn't use Jython here. Jython could wrap / expose the
IB Java API automatically, and then we work a Jython <-> twisted
protocol.

Since most calls require async callbacks anyway, we could just make
everything async...

calls to IB have an ID for retrieving the data which is returned by the
Jython code (increment an integer in the client. The server stores) We
serialize a python object (requestId, remoteMethodNameStr, *args,
**kwargs) so we know what we're getting back. The Jython server knows
the caller and maintains a caller/id for the call it makes to IB (needs
to generate an id for async return anyways... and if its a synchronous
call, it returns the result immediately using the id sent by the client)

For the protocol, it might be possible to use twisted's AMP protocol. I
think that its pure python so it might "just work" in jython.

And we don't lose anything by using a somewhat non-standard interface to
IB because anyone who would want to use the data would want a python
server or our library in their code anyways... just cuz its xml-rpc
doesn't mean its really useful without our libraries... so we might as
well go all the way.

The advantage here is that Jython does all the work of wrapping Java and
of marshalling the data on the java side. To the degree its all the
same on the cpython side, we're kinda done...

not entirely sure about this... but it might be a lot less work.

-glenn