On 2012-07-20 07:17, Mark Rejhon wrote:
On Fri, Jul 20, 2012 at 1:02 AM, Gunnar Hellström
<gunnar.hellst...@omnitor.se <mailto:gunnar.hellst...@omnitor.se>> wrote:
1. I suggest that you add a small section "6.5.7 Editing last
message." with general application information of this feature.
Extensions should not be intertwined by too much information about
each other, but some basic information would be in place here.
Proposal:
The last completed message can be edited through combined use of
the *id* attribute of <rtt/> and application of XEP-0308 [ ]. If
both XEP-0301 and XEP-0308 support is discovered and accepted,
then real-time editing of last message MUST be supported.
This is unnecessary, as I already explained it is backwards
compatible, and Kevin did say it can be supported as-is. I believe
vendors should have the choice of 0301+0308 without enhanced
retroactive RTT, and the suggestion I made (that was +1'd by Peter,
Kevin, and Lance) is backwards compatible.
OK, I modify the end of my proposal to: " then reception of real-time
editing of last message MUST be supported."
2. I suggest that you add a use case "7.5 Example of edit last
message" with a short sequence of editing last and returning to
editing new.
Something based on the examples you have circulated would be fine.
Good idea, but there are a massively huge number of far
higher-priority examples I would like to introduce first (e.g.
improved key press interval examples). I am aware you are also a
strong advocate of key press intervals.
We already have key-press intervals in examples.
It is a risk that real-time editiing of last message will not be fully
understood without an example.
3. Would you consider that a sentence is needed towards the end of
your proposed section on *id* saying
"Before switching from last message editing to current message
editing, the completed last message MUST be committed according to
the rules of XEP-0308 [ ].
Or do you think that that is obvious, or do you intend that
jumping back and forth between last and current may appear without
committing the replacement of the last for every such jump to
current?
What are your thoughts on this? I guess that you think about completing
the edits and send a <body> with replace before sending any edits in the
current message. Is that required? Do you think it is implied by saying
that a 'reset' or other event is needed when you move to editing another
message?
4. I suggest the you delete the word "improved" on line 3. It is
not about improving real-time presentation, t is about providing
it at all.
This is not true. I explained it was 100% backwards compatible, even
it was already pointed out and agreed that UX (User eXperience) may be
strange but nontheless acceptable. Thus, an implementation rather
than an interop issue.
However, I can change the word "improved" into "enhanced" or other
appropriate word.
Your current sentence is:
"to have improved presentation of real-time textduring message correction"
Without the added feature of real-time edit, there is no presentation of
real-time text during message correction. There will be a freeze and wait until
the edit is done and sent as an XEP-0308 replace. So there is nothing there
that can be enhanced or improved. Real-time text presentation during correction
is introduced by the feature.
therefore my proposal is still:
"to have presentation of real-time textduring message correction"
5. I suggest that you delete the words "at all" in the middle of
the *id* section. "used" is sufficient.
Good idea.
Thanks
Mark Rejhon
Thanks
/Gunnar
