> Date: Fri, 19 Jan 2018 12:13:44 -0600 > From: Sam Whited <[email protected]> > I also hope they make it far easier to navigate the XEPs list. When I talk to > developers at events and mention XMPP one of the biggest complaints I get is > "oh, we looked at XMPP but there were multiple things to implement the > feature we wanted and we didn't know what to do" or "we saw the giant list of > extensions and didn't think we'd be able to implement all of them in a > reasonable time frame". Specific examples of this that I've been told include > invisibility (someone at a local Go meetup complained that they tried to use > XMPP but they didn't know if they should use the invisible command or the > invisibility privacy lists XEP) and MAM/message archiving. Having a list of > things to implement feels much more consumable than just seeing the list at > https://xmpp.org/extensions/ and either thinking you need to do all of them, > or having to dig through and find things for your particular feature. Instead > it's nice to have one document that you can be pointed at (or hopefully find > on your own, but that's another problem).
This follows closely with something I've been thinking for a while. There is definitely a need for some form of guidance, not necessarily as prescribed or mandated functionality, but from the viewpoint of "I've implemented XMPP-CORE, now what?" It's easy to point to the ever-increasing list of XEPs and say "take your pick!" but that requires a developer to invest a huge amount of time digging and sifting in order to find which ones are appropriate for their needs. A client developer will most likely already have in mind what features they'd like to implement - it shouldn't be necessary to read through 100+ XEPs in order to work out which ones are needed. What would be really helpful is a summary document that states "For contact pictures you'll need: XEP-0084, and XEP-0153 for compatibility. For file transfer: XEP-0234 is the latest and greatest, with XEP-0047 as a last resort fallback; though some clients have used XEP-0096 in the past, this has since been deprecated. ...etc ...etc." I don't think that needs to be anything as formal as an XEP; a wiki article will probably be the most appropraite place. Some of this information is almost there in various places, but it needs pulling together, organising, and to be placed prominently so it doesn't require a scouring of the dark-web to find it. That being said, I think the Compliance Suites are still worthwhile; but maybe their current form is trying to be too many things to too many people. The problem stems from different people having different ideas of their intended purpose - some want to push forward the state of the art, and some want to document the current state of affairs. Both of these aims can be met with the same document, just not in its present form. The Compliance Suites need a clear statement of aims and purpose, both for what they are and what they are _not_. Overall, they do help serve the purpose of nudging progress in some kind of direction, rather than developers implementing their own random subsets of XEPs they thought looked good, leading to a semi-fractured network where there is limited compatibility between clients either because one doesn't support this feature or does but via a different XEP, or the clients do but one of the servers doesn't. I think Sam has done an excellent job, and I don't expect that anyone else could do significantly better (note the lack of volunteers.) But without an exact outline of aims and purpose, everyone wants to push their own view and some will be in direct conflict with another's, so the task always runs the risk of suffering a slow death by committee - it's hard enough to get a group of people to decide on pizza toppings - as demonstrated by the past five years of non-acceptance.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
