Re: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[Brian E. <azz...@ya...>]

Caleb -

That is exactly our issue. We could be even more fine-grained than we
are, but we attempted to minimize the number of extensions we were
making to the protocol. We felt that adding just the three new extended
field values provided enough information for our clients to know the
true state of their order without causing them to have to do a lot of
coding to support our non-standard values.

We could easily have used another 4-5 statuses, but the net value to
our clients was limited.

- Brian Erst
Thynk Software, Inc.

--- Caleb Epstein <cal...@gm...> wrote:

> On 6/3/05, James C. Downs <jc...@co...> wrote:
> 
> > I'm curious why in your case the OrdStatus = "NEW" was not
> sufficient to
> > indicate that the order was accepted by the exchange and in the
> market? What
> > exchange/venue was most problematic for you in this regard?
> 
> I think the answer depends on how fine-grained you want to make the
> information you pass back to clients of a system.  Especially if
> messages take more than one hop before they go out the door. 
> Consider
> for example this system:
> 
> Client app -> FIX router -> ECNs
> 
> If the FIX router were purely a message-passing application, it would
> just rely on the ECNs to generate all of the execution reports and
> wouldn't generate any of its own.  But what if the Client App wants
> to
> distinguish between a message that:
> 
> * It has created, but not yet sent to the router
> * Has been sent to the router (or we think it has)
> * Has been acknowledged by the router as having been received (but
> hasn't been sent to the ECN yet)
> * Has been sent by the router to the ECN (or the router thinks it
> has)
> 
> And so on.  Different systems may want to have some sort of feedback
> for any/all of these events, so I can see a need for finer-grained
> status codes.  As with routing FIX in general though, the more hops
> you have, the more fields or codes you need if you want to capture
> all
> of the this information.  This can turn into a mess pretty fast.
> 
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com
>