On Wed, 18 Jul 2018 20:40:45 +0500
Ненахов Андрей <andrew.nenak...@redsolution.ru> wrote:
> I'd rather call it 'extended chat state notifications' or something
> like that. Recording audio is only distantly related to file sharing.

I can see your point, but I don't think that the name 'Extended Chat
State Notifications' describes the XEP better.


On Thu, 19 Jul 2018 15:48:42 +0200
Jonas Wielicki <jo...@wielicki.name> wrote:
> 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 :).

Ah ok, I understand that better now. :)

> 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.)

Makes sense. +1

> In the Business Rules I think you meant "When sending a <creating/>
> or <uploading/> notification […]" (instead of ``composing``)).

Yeah, will fix that.

> 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.

I somehow thought of <paused/> as stopped writing instead of actually
pausing. Then going back to <active/> <inactive/> makes more sense of
course.

> I think this section can use some structural improvement. How’s this?
> (I also changed the rules a bit, see below):
> [...]

I think that's easier to understand.

> - 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?)

I think using something as 'in the last 10 seconds' makes the
implementations much more complicated. Another option would be to just
send no <composing/> at all as it is currently.

I agree with you on the other points.

Regards,
Linus
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to