[Standards] Proposed XMPP Extension: File Sharing Notifications

Jonas Wielicki jonas at wielicki.name
Mon Jul 23 14:58:24 UTC 2018

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180723/5d6449cd/attachment.sig>

More information about the Standards mailing list