On Tue, Aug 21, 2007 at 11:02:09AM -0600, Joe Hildebrand wrote: > > On Aug 21, 2007, at 5:15 AM, Remko Tronçon wrote: > > >When 2 resources are logged in with the same priority, it's probably a > >lot worse to just let the server pick one, because it will pick the > >wrong one in 50% of the cases. > > Not if you use a better algorithm. You've got information from > presence that helps you make a better choice than coin-flip. > Timestamps, show, etc. are really good at tie-breaking in the real > world.
Will that algorithm be a 100% solution or will it just reduce the chance of picking the wrong resource? I think that the solution to this problem should be a 100% one, because it's an essential part of XMPP to deliver messages. I would rather like a deterministic 'send to all resources with the same priority' than some heuristic (which can fail) on the server side the user doesn't know about. If the proposed algorithm goes into a 'best practices' document we will likely end up with only 'some' servers implementing leading to a inconsistent experience for the users of those servers. I don't expect users to read some website somewhere to figure out whether the server does what he expects. Some users of course don't even know what to expect. But the 'send to all resources with the same prio' approach will seem consistent to them and I argue that this will give the user a more safe feeling that he just gets the message than having to worry about servers doing funny stuff to figure out where a message should go to. About the nice 'sell 50 shares' example: There is delayed delivery indeed. Will your proposed algorithm provide a 100% solution to the problem and is also the most likely thing a user expects? Can it also be explained to a user easily? Or will we have to tell them "there is some algorithm which is around multiple pages long that determines whether you get that message or not"? Robin
