Trustin Lee wrote: > On Nov 13, 2007 2:05 PM, Mike Heath <[EMAIL PROTECTED]> wrote: >> I really don't see a need to change the API to support a feature that >> few people will use. Using IoSessionDataStructureFactory to produce a >> priority queue provides the necessary flexibility to allow those who >> need this feature to implement it for their protocol as they see fit. > > The problem is that WriteRequestQueue can't effectively determine the > priority of the scheduled message because it will be in a binary form > in most transports. The WriteRequestQueue implementor must know the > original message of the final binary form. Should we add > WriteRequest.originalMessage property instead then?
Oh you're right. I was thinking we would still have the original message when the message was put into the WriteRequestQueue. WriteRequest.originalMessage could be used to solve the problem and it might be useful for other types of custom WriteRequestQueue implementations. Is there a better solution for this? What if we did change the API and used a priority queue by default? Is the overhead incurred by using a priority queue over a normal queue high enough that we wouldn't want to do that? I can't see there being much overhead at all if the priorities are all the same (the default case). -Mike
