On Tue, Jul 17, 2012 at 7:08 PM, Mark Rejhon <[email protected]> wrote:
> On Tue, Jul 17, 2012 at 6:24 PM, Lance Stout <[email protected]>wrote: > > > And the bottom line -- is there interest from anybody else in the list for me to add the optional 'id' attribute to XEP-0301? I'd keep it as a modification in reserve, to be added only when XEP-0308 becomes draft. Unless anyone believes I should cover it in XEP-0301 right now, today? It's such an edge case today, but is there interest from others in including it in XEP-0301 right now? Note: It sort opens a Pandora's Box if we discuss it *right now*. If added, the question for X-message rectroactivity (editing messages 2 messages ago, or 3 messages ago, etc) will eventually need to be answered. XEP-0308 seems to leave the door open to the ability to do X-message retroactivity, and XEP-0301 can follow suit on that, keeping things in sync. The "msg" attribute I used to have in an early 0.0.1 version of XEP-0301 allowed multiple-message retroactive editing, which is useful for editing of transcriptions (deaf interpretors, conferences, court reporting, etc) -- requires X-message-ago retroactive editing. This is easily done as a private extension to XEP-0301. Now on this subject, there are complications: The sorting of retroactive editing of messages of retroactive editing done to messages that no longer exist in that current chat session -- when retransmitted, it will repopulate, but if the order of editing is random, then the messages repopulated may not be in the same order they used to be delivered in. Old messages being edited after logging in (i.e.messages delivered to a different chat session), which is more complicated for the current 'id' proposal than the old numeric 'msg' proposal, since a series of message resets can just re-populate chat history, or perhaps use XEP-0138 Message Archiving to repopulate the chat history before allowing retroactive editing to it. (Though Message Archiving wasn't designed for that purpose!) Anyway, another alternative is simply sorting repopulated retroactive messages by the alphabetical ordering of the 'id' attribute, but that sounds like a hack. Things dramatically simplify if we just say only the previous message can be edited (rather than several messages ago), but I don't like the idea of limiting to that, either. Anyway, end of the pandora's box angle. :-) Thanks Mark Rejhon
