On Mon, Aug 13, 2012 at 12:22 PM, Kevin Smith <[email protected]> wrote: >> Anyways, if there's no particularly strong reason to have the "last" message >> restriction, I think it should be removed. > > The spec originally allowed previous non-last correction, and the > community cried foul so I removed it. > > I can add it back in if the community has now changed its mind!
It's useful for real-time text situations -- it goes hand-in-hand with transcription/caption corrections, when using instant messaging as a conduit of transmitting transcriptions, and needing to retroactively fix transcription errors, or manually editing voice-recognition errors. It is a niche case, but certainly a legitimate one. However, please bring the original people who cried foul, back into this discussion. I'd like to see if they now agree with the use cases. The only thing is that you need to either: 1. Define the bounds of corrections (e.g. X messages ago) --or-- 2. Define what to do if 'id' points to a non-existent message (i.e. refers to a message that no longer exists on recipient's client -- this can happen in multiple login situations, reconnect situations, MUC situations with new participants joining after a message is already sent) For simplicity you may want to go for scenario (2) for now. Treat unrecognized id's as a new stanza. The only problem is that we don't really know "how many messages ago it was" -- for example, we don't know if it was 2 or 3 messages ago -- or 6 messages ago. So corrections done in a random-access manner, and out-of-order transmission, will show potential jumbling of order. But that's acceptable, and potentially a client implementation could automatically sort the 'id' parameter alphabetically, since the 'id' is often always incrementing (either numerically or alphabetically), though that's not always reliable. Thanks, Mark Rejhon
