Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
Sorry I haven’t been posting here for a while concerning refining a book proposal.
It seems the rough consensus is to use Quote Request / Quote rather than specifying a separate Book Request / Book set of messages. One of the things I don’t see is a way to reject a Quote Request which will be necessary for book functionality. (I.e. requesting depth of book if you’re not authorized to see it, requesting a feed of all stocks if you don’t have the bandwidth to support it, etc.)
I see two ways of doing this:
Do it the same way as Cancel Rejects are implemented. Create a third message type called Quote Reject.
Disadvantage: It eats up a message type when free single-character types are getting rather scarce.
Do it the same way Orders are rejected. Create a QuoteRejReason field and put it in the quote message.
Disadvantage: It complicates the requirement state of fields in the Quote message. I.e. certain fields which may be required would then only be conditionally required, the condition being that QuoteRejReason is not present.
I’m sort of leaning towards the second approach, since I’m thinking that for efficient book updates, certain fields which are required in a Quote message may no longer need to be required. I.e. if it’s established that one message is the book update for INTC, there’s no need to repeat INTC with each bid or offer. If we’re making a lot of required fields conditional, then adding one additional condition won’t be that much harder to implement.
Of course I’m not adverse to the first approach; I just want to make sure we look at the other alternatives before creating a new message type.
Comments?
I prefer the second approach but you would also want to add QuoteType (with Reject being an option along with the typical New, Cancel, Replace) and QuoteRejReason.
> Sorry I haven’t been posting here for a while concerning refining a book proposal.
>
> It seems the rough consensus is to use Quote Request / Quote rather than specifying a separate Book Request / Book set of messages. One of the things I don’t see is a way to reject a Quote Request which will be necessary for book functionality. (I.e. requesting depth of book if you’re not authorized to see it, requesting a feed of all stocks if you don’t have the bandwidth to support it, etc.)
>
> I see two ways of doing this:
>
> Do it the same way as Cancel Rejects are implemented. Create a third message type called Quote Reject.
>
> Disadvantage: It eats up a message type when free single-character types are getting rather scarce.
>
> Do it the same way Orders are rejected. Create a QuoteRejReason field and put it in the quote message.
>
> Disadvantage: It complicates the requirement state of fields in the Quote message. I.e. certain fields which may be required would then only be conditionally required, the condition being that QuoteRejReason is not present.
>
> I’m sort of leaning towards the second approach, since I’m thinking that for efficient book updates, certain fields which are required in a Quote message may no longer need to be required. I.e. if it’s established that one message is the book update for INTC, there’s no need to repeat INTC with each bid or offer. If we’re making a lot of required fields conditional, then adding one additional condition won’t be that much harder to implement.
>
> Of course I’m not adverse to the first approach; I just want to make sure we look at the other alternatives before creating a new message type.
>
> Comments?
>