Invaluable indeed. I've studied the docs, installed the product, <br>and have been following the discussion, and am extremely impressed.<br><br>Thank you Bill and other project members for sharing your thoughts and <br>
resulting work. <br><br>BTW, I would also love to see any more info, or better yet even an alpha <br>version of a sample client to help tie things together. I suspect that some <br>or many here may know enough to appreciate the elegance and sophistication <br>
of the shim concept and product, but like myself struggle to produce a client from <br>the ground up. <br><br>In any event, the main point is thanks.<br><br>Regards,<br>Michael<br><br><br><br><div class="gmail_quote">On Fri, Aug 28, 2009 at 23:09, Ken Feng <span dir="ltr"><<a href="mailto:kfmfe04@gmail.com">kfmfe04@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Bill,<br>
<br>
I appreciate your taking the time to comprehensively describe a<br>
sensible approach to designing the downstream client. It's a great<br>
wrap-up, answering many of the questions I have had this week on the<br>
mailing list.<br>
<br>
The examples in exs are fantastic for getting our feet wet, but as you<br>
mentioned,<br>
<div class="im"><br>
> It would be nice to provide example code via a ruby sample client,<br>
> and that's just one of many things we haven't completed yet.<br>
<br>
</div>I look forward to seeing an example one of these days, but I believe<br>
you have provided enough of a roadmap for me to continue coding an<br>
approach in Ruby. Generally, I am indifferent to a particular<br>
language or platform, insomuch as picking a tool doesn't "make life<br>
hard for me" in terms of implementation or maintenance.<br>
Unfortunately, my engine for generating signals/orders in C++ is<br>
sufficiently large/complex that I do need to interface to it somehow.<br>
As you have very well described in your posts, I share you abhorrence<br>
of any thought of duplicating such code. I was walking down the<br>
approach of a "poor man's IPC" via MySQL and crontab'ed writes and<br>
reads into the database, but I may be able to avoid that with your<br>
Ruby hints.<br>
<br>
My indifference towards languages has also led me to a hodge-podge of<br>
programs and tools for getting the job done. I am fine with this, but<br>
it is certainly not pretty for other developers who are trying to<br>
understand my code - but that's a different story.<br>
<br>
Having said that, I actually like Ruby and prefer it over all others<br>
for any type of scripting (though I hear Python is also quite good) -<br>
Ruby's conciseness, intuitiveness, richness of API, and delivery of<br>
its promise of "least surprises" are all quite impressive. I will<br>
definitely search popen3() and select() in Ruby - thank you for<br>
pointing me in the right direction.<br>
<br>
I will hard-code my triplet response code this time in Ruby, but I do<br>
look forward to the day when I can refactor it to be driven by a shim<br>
table instead.<br>
<br>
BTW, if you haven't done so already, I hope you do copy-and-paste<br>
these three posts into the new documentation.<br>
<br>
I am certain that users who are at the last stage of downstream client<br>
design/development would find these notes invaluable, as I have.<br>
<br>
Regards,<br>
<font color="#888888">Ken<br>
</font><div><div></div><div class="h5"><br>
On 8/29/09, Bill Pippin <<a href="mailto:pippin@owlriver.net">pippin@owlriver.net</a>> wrote:<br>
> Ken,<br>
><br>
> With respect to your questions about downstream architectural<br>
> approaches to the IB tws api, this post focuses on the following<br>
> question:<br>
><br>
> How might a ruby sample client, an example program to interface<br>
> with the shim, be designed, what parts of the code would be<br>
> provided, what parts would be supplied by client users, and in<br>
> the absence of such a sample client in the shim tarball for now,<br>
> what might users write in its place?<br>
<br>
><br>
> To recap, such a program would apply user-specific criteria to perform<br>
> the following types of tasks:<br>
><br>
> * ask for market data;<br>
> * interpret such data;<br>
> * generate orders; and<br>
> * manage positions.<br>
><br>
> Once given an IB tws account, and the shim, then the shim command<br>
> language would be used to generate api requests, and the shim cout<br>
> option could be used to ensure that the resulting message traffic,<br>
> and indeed the entire integrated event stream, were accessible to<br>
> the client. That much is obvious, and leaves us a long reach from<br>
> the task goals above. What else?<br>
><br>
> A. Main.<br>
><br>
> Once given initialization, about which more later, there would be<br>
> a main loop to process events; input for that loop would be read<br>
> via the select() system call, provided in ruby; and the two input<br>
> streams from the shim provided via the popen3() system call, the<br>
> stdin and stderr, would be multiplexed via select() . The input<br>
> would be selectively converted to event objects via table-driven<br>
> code, which brings us back to initialization.<br>
><br>
> B. Init<br>
><br>
> Prior to entering the main loop, event descriptions from a sql<br>
> database would be read in, and used to generate: event classes, the<br>
> related data members, and constructor code which would take as<br>
> input a split array from a text input line. The result would be an<br>
> admittedly large quantity of automatically generated boilerplate<br>
> none of which would need or warrant human maintenance.<br>
><br>
> C. Processing<br>
><br>
> The client user would still be responsible for writing: the<br>
> definitions of non-empty process operations for each message event;<br>
> as well as strategy code that would use input from such processing,<br>
> presumably to generate signals and/or orders.<br>
><br>
> D. User input<br>
><br>
> The client user would still be responsible for writing: gui screens,<br>
> or code to accept yet another layer of downstream command input, if<br>
> so desired. As previously noted, the select() system call could be<br>
> used to multiplex the three input streams of other client/human<br>
> control, events from the shim cout, and exceptional messages from<br>
> the shim stderr.<br>
><br>
> E. What for now?<br>
><br>
> As for (c) and (d), above, that's the user's responsibility in any<br>
> case, and so about which no more.<br>
><br>
> As for (a), users should already be using popen3() or its equivalent<br>
> in their favorite scripting language, and select() ditto, in any case;<br>
> or else they may choose threads, in which case that's their business,<br>
> and outside the scope of these list messages.<br>
><br>
> It would be nice to provide example code via a ruby sample client,<br>
> and that's just one of many things we haven't completed yet.<br>
><br>
> As for (b), this is the serious gap, and all I can say is that study<br>
> of rule.c and apis.c may help, but is a non-trivial effort. I fully<br>
> intend to define sql create table and insert statements to provide<br>
> table definition of the api events, but such work is intimately coupled<br>
> with versioned api-level event processing, our next major work effort.<br>
> It's just not done yet. Sorry. Feel free to read rule.c, and apis.c,<br>
> and for that matter EClientSocket.java and EReader.java.<br>
><br>
> Thanks,<br>
><br>
> Bill<br>
><br>
> _______________________________________________<br>
> ts-general mailing list<br>
> <a href="mailto:ts-general@trading-shim.org">ts-general@trading-shim.org</a><br>
> <a href="http://www.trading-shim.org/mailman/listinfo/ts-general" target="_blank">http://www.trading-shim.org/mailman/listinfo/ts-general</a><br>
><br>
_______________________________________________<br>
ts-general mailing list<br>
<a href="mailto:ts-general@trading-shim.org">ts-general@trading-shim.org</a><br>
<a href="http://www.trading-shim.org/mailman/listinfo/ts-general" target="_blank">http://www.trading-shim.org/mailman/listinfo/ts-general</a><br>
</div></div></blockquote></div><br>