[ts-gen] New OCA group use case [Was: Parent/child OCA groups ...]

[Ken Feng]

Hi Bill,

> So, lmt orders guarantee price but not execution, and stp orders,
> fill but not price.

Yes, that is an excellent way of looking at it.

FWIW, the use of STP orders to open a trade is a very strange idea for
most people - I have met many stock traders who can't get their mind
around why anyone would want to buy above the market price or sell
below.  But one interesting way of looking at it is, there is,
mathematically, no difference between a stop loss (to close an open
long order) and a sell stop order (to open a new short trade).  Of
course, some governments would like to categorize them differently and
call the former a SELL order but the latter a SHORT-SELL.  Ignoring
that bit, there really is no difference.

If that doesn't seem to make sense, consider that there really is no
difference between buying first and then selling, and selling first
and then buying.  These types of symmetries are much more explicit in
the futures markets (margin/exposure based) and less so in the equity
markets (cash/physical based), but it is more due to
institutional/historical bias than some inherent mathematical
difference.

> Perhaps more of interest for you, the next planned minor feature -- fix
> is for the formatting problems people have noted, and I'll probably
> start on that next week.  Barring some particularly embarrassing or

Yes, that would be nice.

> especially trivial bug --- those tend to jump the queue --- I'd be
> glad to make some form of additional oca group notation for the create
> order command the follow-on minor feature, so hopefully you might
> expect to see progress, or at least work started, for your explicit
> OCA group feature week after next; when minor features take longer
> than the day or so set aside for them, I simply continue them on to
> the next week.  E.g., looking at the sources, you'll see that work
> on the concurrent session problem spread over two or three weeks.

Great - I look forward to using it/testing it out for you.

Meanwhile, I will try to implement a temporary "poor man's OCA" at the
Ruby layer, which might not be a bad thing for now, because it will
force me to do what I was avoiding for a while - which is detecting
fills on the fly.

I know that "select open;" will pull me the open orders, but I wonder
if fills are automatically pushed in through to ShimText - I will have
to check and see...

- Ken