On Nov 14, 2007 9:39 AM, Trustin Lee <[EMAIL PROTECTED]> wrote: > On Nov 14, 2007 5:15 AM, Mike Heath <[EMAIL PROTECTED]> wrote: > > 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? > > I think adding originalMessage property will fix this issue. > > > 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). > > That's also a good idea, but this doesn't mean than originalMessage > property is not needed. WriteRequestQueue implementors will want to > inspect some property of the original message to determine (or > override) the priority of the message automatically. > > Considering originalMessage is required anyway, we could simply end up > with adding originalMessage property and retaining the current write() > method. However, having some kind of priority mechanism (i.e. high > priority queue + low priority queue) might be useful to many users > although it will take up some additional memory. I'd like to know > what others think about this issue.
I've just added WriteRequest.getOriginalRequest() which should enable users to implement his or her own prioritized WriteRequestQueue. I think this change doesn't consume any additional memory because any transformed WriteRequest has its parent request in itself already. The default implementation doesn't consider priority at all though. Again, any user feed back is welcome. :) Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
