Hi Gordon, 2009/9/15 Gordon Sim <[email protected]>
> I think clunky is a fair description of the current capabilities and I > think we can improve on that. > > My view of what ideal 'LVQ' behaviour whould be like is that the 'queue' > would really be more like a 'topic' where the last message for each key was > always saved. Clients would subscribe to it and receive the last message > published for each key and subsequently any updates (i.e. any new messages). > > I.e. it would do pretty much what you describe, but through a simpler > interaction. The client would just need to 'subscribe' to the 'LVQ'. > > I would think that in JMS this would be made available as a Destination you > could create consumers and producers from for normal use. It would behave > more like a JMS topic than a queue though (i.e. consumers would not compete > for messages). > > Are there other views or use cases on what it should do? > > The above is pretty much how I would like an LVQ to behave... Indeed I have a patch for the Java Broker to provide just such LVQ functionality, which I should get round to applying for 0.6. The only real question is do you inform subscribers of *all* updates... or, if the subscriber starts to fall behind, do you only send updates that have not themselves already been superceded (my Java implementation does the latter). Cheers, Rob
