Re: [Standards] Proposed XMPP Extension: File Sharing Notifications
On Montag, 23. Juli 2018 16:26:45 CEST Ненахов Андрей wrote: > сб, 21 июл. 2018 г. в 1:46, Tedd Sterr : > > > I'd rather call it 'extended chat state notifications' or something > > > like that. Recording audio is only distantly related to file sharing. > > > > "Media Stream Activity Notifications (MSAN)", then. > > > > But it's good that we're putting so much effort into arguing over the > > important details, rather than trivial things like the actual protocol. > Actual protocol is rather trivial. It took us a grand few hours to > implement all required functionality with attribute and kinda within > existing XEP-0085. Would not take much longer to make it like it's > purposed here. However, I do somewhat object to adding yet another > XEP, especially with misleading names. Feel free to suggest a better name. Naming is hard and easy at the same time. > This creates barriers for > developers and requires more bureaucracy work (some people like doing > bureaucracy work, though). Maybe updating 'final' standard in a > non-breaking way is a lesser evil than adding more and more XEPs. See, I understand this, but there’s a trade-off to find here. I personally find that lean, short, self-contained XEPs are preferrable over a single huge XEP. This is for two reasons: - It promotes separation of concerns on the protocol level, which helps to bring that even into the software, which is nice for modularity and thus, in the end, code quality. - It makes the individual documents easier to digest and reason about. (Of course, "short" is very dependent on the subject matter.) Now, I understand that having gazillions of XEPs also has its own downsides. However, I think that those downsides can be mitigated easier than the downsides of a single huge XEP. The downsides are (in my view): - It is unclear to developers which XEPs are important to implement. - A large number of documents makes it seem much more intimidating than a single large documentation which describes, e.g., a REST API. We need to work on mitigating those downsides, but this is independent of the question whether we want to modify Final XEPs and allow feature creep in existing XEPs or not -- because we will eventually end up with a considerable number of XEPs (some would argue we’re there already). However, I think that issue is out-of-scope for this XEP. In addition to this, having a point where a standards document becomes -- aside from editorial fixes -- immutable is very beneficial, because it allows implementations to rely on this exact behaviour. It is certain that it won’t change and that other implementations which may implement an older version will eventually converge to this state. Modifying a Final document breaks all those guarantees. As a client developer, I find those guarantees appealing. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: File Sharing Notifications
сб, 21 июл. 2018 г. в 1:46, Tedd Sterr : > > > I'd rather call it 'extended chat state notifications' or something > > like that. Recording audio is only distantly related to file sharing. > > "Media Stream Activity Notifications (MSAN)", then. > > But it's good that we're putting so much effort into arguing over the > important details, rather than trivial things like the actual protocol. Actual protocol is rather trivial. It took us a grand few hours to implement all required functionality with attribute and kinda within existing XEP-0085. Would not take much longer to make it like it's purposed here. However, I do somewhat object to adding yet another XEP, especially with misleading names. This creates barriers for developers and requires more bureaucracy work (some people like doing bureaucracy work, though). Maybe updating 'final' standard in a non-breaking way is a lesser evil than adding more and more XEPs. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: File Sharing Notifications
On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. Again, the ProtoXEP has been updated. Available under the same URL. > Title: File Sharing Notifications > Abstract: > This specification provides a notification protocol for information > about ongoing file uploads and media creation by the user. > > URL: https://xmpp.org/extensions/inbox/fsn.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: File Sharing Notifications
> I'd rather call it 'extended chat state notifications' or something > like that. Recording audio is only distantly related to file sharing. "Media Stream Activity Notifications (MSAN)", then. But it's good that we're putting so much effort into arguing over the important details, rather than trivial things like the actual protocol. (See also: https://en.wikipedia.org/wiki/Law_of_triviality) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: File Sharing Notifications
On Wed, 18 Jul 2018 20:40:45 +0500 Ненахов Андрей 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 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 > or 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 as stopped writing instead of actually pausing. Then going back to 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 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 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 ___
Re: [Standards] Proposed XMPP Extension: File Sharing Notifications
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 or 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 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 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 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 >instead of . > - After the upload finishes or is aborted, the normal XEP-0085 logic takes > over. Normally, this will put the conversation into or >state (but if the user still has input pending, it may also > be ). > > 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 state), it MAY treat interaction with the media > selection like text input in XEP-0085 (i.e. send while the user > is actively engaging with it and switch to if inactive for a > certain time). Changes: - 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 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. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: File Sharing Notifications
On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. The proposal has been updated. The new version (0.2.0) is available under the same address as before. > Title: File Sharing Notifications > Abstract: > This specification provides a notification protocol for information > about ongoing file uploads and media creation by the user. > > URL: https://xmpp.org/extensions/inbox/fsn.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: File Sharing Notifications
On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: File Sharing Notifications > Abstract: > This specification provides a notification protocol for information > about ongoing file uploads and media creation by the user. > > URL: https://xmpp.org/extensions/inbox/fsn.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. I like the intent of this XEP. I think it can be improved by loosening the coupling between XEP-0085 and this one. I suggest to focus on the new functionality provided by this XEP in the Use Cases section and add another (sub-)section which describes *suggested* XEP-0085 states which MAY be sent alongside of the states described by this XEP. This helps untangle the reading a bit and having the "compatibility" part in a single place makes it easier to reason about (side-)effects of this. Also, RECOMMENDED is equivalent to SHOULD, OPTIONAL is equivalent to MAY. The statement > However, adding chat states is RECOMMENDED, but OPTIONAL. is thus contradictory. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: File Sharing Notifications
I'd rather call it 'extended chat state notifications' or something like that. Recording audio is only distantly related to file sharing. ср, 18 июл. 2018 г. в 20:34, Jonas Wielicki : > > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: File Sharing Notifications > Abstract: > This specification provides a notification protocol for information > about ongoing file uploads and media creation by the user. > > URL: https://xmpp.org/extensions/inbox/fsn.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
