[Standards] Proposed XMPP Extension: File Sharing Notifications
jonas at wielicki.name
Thu Jul 19 13:48:42 UTC 2018
On Donnerstag, 19. Juli 2018 15:28:20 CEST Jonas Wielicki wrote:
> On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote:
> > URL: https://xmpp.org/extensions/inbox/fsn.html
A few more remarks. I’d normally against giving non-critical feedback in
ProtoXEP stage, but given that the Council is on vacation next week, it makes
may sense to sort out the rough edges now.
A requirements section is very much needed. "Requirements" is meant as in
"What is required of the protocol?" and not as in "Dependencies". So here
you’d probably have something like:
> * Convey upload state
> * Distinguish media types
> * Convey recording state
> * Signal cancelling of uploads
> * Allow co-existence with XEP-0085
> * Define recommended rules for interop with XEP-0085
Just with fancier words :).
Looking at the first table: I suggest to use the same definition of types for
both uploading and recording. Animation may not make sense (and we can
discourage use with SHOULD NOT) for recording, but having the same set of
values for both seems better to me.
Especially since an audio recording is not necessarily a voice recording (if a
client chooses to present it if it was, that’s fine; it doesn’t need to be
reflected on the protocol level.)
In the Business Rules I think you meant "When sending a <creating/> or
<uploading/> notification […]" (instead of ``composing``)).
I’m also not sure forcing ``paused`` here makes sense. If the upload failed,
the user may not be actively looking at the screen and thus a ``paused`` state
may be confusing to the recipient. If the user aborted the upload, they may
have decided to not share anything after all.
In both cases, going back to ``active`` or ``inactive`` (whichever is true)
seems more appropriate to me.
Remove the "Of course" from the third paragraph and replace it with a MUST. I
would suggest to not force <active/> state, because the user might not be
actively engaged in the conversation or even with the device at the time the
upload finishes. Use whatever XEP-0085 state is appropriate.
I think this section can use some structural improvement. How’s this? (I also
changed the rules a bit, see below):
> When a sending client chooses to map FSNs to XEP-0085, it MUST follow the
> following rules:
> - As long as no upload or creation is in progress, the normal XEP-0085
> states are sent.
> - During creation, a client MUST send <composing/> state (overriding the
> state which would normally be sent with XEP-0085 logic).
> - During upload and while the user is active, a client SHOULD continue to
> send the <composing/> state (overriding the state which would normally be
> sent with XEP-0085 logic).
> - During upload and while the user is inactive, a client SHOULD send
> <inactive/> instead of <composing/>.
> - After the upload finishes or is aborted, the normal XEP-0085 logic takes
> over. Normally, this will put the conversation into <active/> or
> <inactive/> state (but if the user still has input pending, it may also
> be <paused/>).
> A client MAY choose not to apply this mapping if it allows text input while
> creating or uploading media, to allow transmitting normal XEP-0085 states
> for the text input.
> If a client allows a user to pick media which are already created (thus
> skipping the <creating/> state), it MAY treat interaction with the media
> selection like text input in XEP-0085 (i.e. send <composing/> while the user
> is actively engaging with it and switch to <paused/> if inactive for a
> certain time).
- Make it clear that after the upload is over, normal XEP-0085 rules take over
(instead of forcing any XEP-0085 state).
- Use MUST for creating and SHOULD for uploading; I think for uploading we’ll
have to see how this actually looks and feels to users, especially with long
uploads (maybe it would be nice to only show <composing/> in the last
(approximately) 10 seconds of an upload?)
- Add rules for clients which allow text input while uploading.
- Add rules for states while picking a file.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards