[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT
markybox at gmail.com
Tue Jul 17 23:57:44 UTC 2012
On Tue, Jul 17, 2012 at 7:08 PM, Mark Rejhon <markybox at gmail.com> wrote:
> On Tue, Jul 17, 2012 at 6:24 PM, Lance Stout <lancestout at gmail.com>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. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards