Le lundi 3 juin 2024, 14:58:23 UTC+2 Marvin W a écrit : > It's not as soon as your change causes incompatibility issues with > other clients if they don't follow and also "move fast" and implement > experimental functionality - and if everyone needs to follow yours to > be compatible, it's effectively stable, because changes can't be done > without breaking compatibility again. So we should just move forward > and call it stable, and be happy to fork into a new XEP number that > supersedes the old one if needed.
Changes don't cause incompatibilities, we have namespaces to handle that. You can perfectly adapt to the change according to namespace. The issue is that people are afraid that other won't implement new things. > > > The "experimental" state is clear: it may change and break. > > That seems to not be clear to anyone, to be honest, especially not end- > users and also not in how we market our products. > > OMEMO is in Experimental and yet a lot of clients feature it as regular > functionality and breaking it would have terrible consequences and > render communication between some clients impossible. Realistically, > siacs OMEMO (XEP-0384-v0.3) is in fact a stable specification, even if > we wanted to and eventually did breaking changes to it afterwards. It's > a mess. The cleaner way would have been to advance v0.3 to stable and > do a new XEP for a second version OMEMO that is what the current XEP. My client implements both old and new OMEMO and adapts to the right version thanks to namespaces. Doing a new XEP would not have changed anything. People have implemented OMEMO because there was a need (and pressure from users and other IM solutions). Waiting for a new version years later would have only put XMPP in oblivion. Now, projects have to handle priorities, and the current version is working well enough that they handle the implementation when it makes sense to them. Also the "proper" new version is more difficult to implement, so it makes sense that it's done progressively. > > If I want to go to the extreme, I'd say that if something needs a > namespace version bump, because an incompatible change was made to a > specification that was already implemented and deployed, something went > wrong. One XEP should match exactly to one namespace and a new version > should just be a new XEP. I totally disagree on that. Namespace bumps are not that expensive and should be used freely in experimental XEPs. But my position is known there, so there's no need to continue in circles forever. I would like to see other inputs. > > > I agree it shouldn't be mandatory, but also we should encourage not > > > only talking with the community before writing the XEP, but also to > > > talk with the community before experimenting with the ideas. > > > Because > > > others might have done that before and/or have ideas that are worth > > > including in the experimentation. The XEP creation process starts > > > with > > > the idea, not when writing it down, and IMO we need to find ways > > > and > > > provide the tools to support XEP creation before the formal writing > > > process. If they have done it before there should be an experimental XEP. My point is actually that experimental XEP should be easier to produce. And we may not all work the same way, but implementing, and writing specification can go in parallel to clarify and draft an idea. Then experimental is there for community feedback/update/experiment cycle. > > Once again, experimental is for that. Writing things down helps to > > clearly > > explain them and how we intend to do them. It's not a starting point > > for a > > feature, but it's definitely a good starting point for wider > > discussions. > > Experimental certainly is not the place to just dump an example. I've never said that. I've just said that the current situation, and I've actually said that it's not good. It's actually quite the opposite: my point is that I would like to make it easy to create a minimal specification, with enough information to be implementable. A Council vote would ensure that the minimal requirements for an implementation are there, and then the feedback, update, and experiment cycle can start. This would be far better than having to rely on specifications, code, and dump snippets scattered all over the web. > You > also don't create an Experimental XEP "I want to do Remote Control and > will upload content here in 2 months after my experiments" - Why is that? People can try to implement this version and give feedback on what is good, bad, or ugly, or even without implementing it. Why would it not be okay to update it based on experiments and feedback after a period of two months? > but I > would want to encourage both public pre-announcements and a place to > publicly scribble ideas. Of course writing things down properly helps > to find these things, but it also means that the process takes longer > and feedback and collaboration will only be possible at a later stage - > which can worst case mean more wasted energy and time, and we all don't > really have energy and time to waste. Of course, the process would take longer: pre-announcement, explanation, waiting for feedback (how much? 24 hours? 2 weeks?), understanding feedback, explaining that the idea was not understood correctly, etc. Here, everybody knows that work is done on a specific topic when protoXEP is submitted, work has started, everybody can read the spec to see exactly what is it about and the vision of the author, and feedback. I don't says that pre-announcement is a bad thing, but it's clearly delaying everything and may actually make things more complicated. > The problem is that people DO implement features based on Experimental > and consider this de-facto stable. That's why we do namespace version > bumps: because developers don't expect the XEP to break, otherwise it > would be no issue to change things in breaking way without namespace > version bump. Reality is: The big red warning doesn't change how people > see Experimental XEPs and claiming it bigger while not changing how we > actually treat it really isn't going to change it. I don't see a problem that people do implement experimental feature, but if they consider it as stable, that means that they can't read big red warning (or just the warning and state, people may be colorblind). Not sure about others, but I do implement experimental feature, I do expect them to break, and I'm not worrying because there are namespaces. Actually, why do you even think that developers don't expect the XEP to change? "break" is not even the right word here because they don't break precisely because there are namespaces. > Gaining experience and feedback from others and discuss doesn't require > to publicly release and distribute software that uses it to a large > userbase. Experimental is totally for these things: experimenting, > discussing, incorporating feedback. It's not for production, because > then you typically can't break anymore without terrible consequences. Certainly not "publicly release and distribute software that uses it to a large userbase", who has said that? A first draft of a specification describing what is the idea, what is it used for, and how to implement it is certainly very much useful. Regarding the choice of implementing or not something, it's the job of developments teams, not of XSF. > [SNIP] > > As explained above, reality shows that this is not the case. OMEMO > being a perfect example. We'll be stuck with a shitty version of it > probably for another decade because people implemented it into > production while it was pre-Experimental or still very much > Experimental. So I do disagree, people don't consider the consequences > of Experimental XEP because in practice, we consider Experimental XEPs > stable and will namespace bump instead of doing breaking changes, so > there are no compatibility issues. And clients tend to implement > multiple versions of Experimental XEPs for good interoperability. No, OMEMO was implemented due to need and pressure, and it's a good thing that it was done because it took years to have a good version. In the meantime, support for OMEMO has been advertised as a strength of XMPP in literature for years. It is absolutely possible to have old and new versions running in parallel (my client does it), and clients will eventually do so when the need arises. There are already several clients implementing OMEMO:2. > XSF can go as far and say "Client X is not compatible with XMPP as it > implements a protocol that is still Experimental". We do keep a list of > clients that "implement XMPP" so it is within the scope of the XSF to > decide what it means to be an XMPP client and requiring that only > stable specifications must be enabled in the default configuration of a > client to be considered an XMPP client is certainly valid. So, clients that implemented OMEMO when it was just a web page outside of the XSF would no longer be considered "XMPP clients"? If you want to kill XMPP once and for all, that's probably the best way to do it. Best, Goffi
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
