On Montag, 23. Juli 2018 16:26:45 CEST Ненахов Андрей wrote: > сб, 21 июл. 2018 г. в 1:46, Tedd Sterr <teddst...@outlook.com>: > > > 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 _______________________________________________
