2 Jun
2024
2 Jun
'24
12:30 p.m.
Thanks Dave,
I really appreciate you kicking off this discussion.
On 27/05/2024 15.07, Dave Cridland wrote:
I've rejected protoXEPs as arbitrarily as anyone
else when in Council,
but loosely a few things crop up repeatedly:
* Unwarranted duplication of effort: The problem being solved is already
at least partially addressed by an existing solution, and it seems
better to fix that than wholesale replace it.
I am very skeptical to have any kind of "duplication" criteria.
First, in some cases there is no one-size-fits-all. Very possible that
we we will not end up with the one-and-only XMPP IoT protocol
extensions. But maybe multiple with different goals and tradeoffs.
Secondly, the XSF should not encumber competition. At least not in early
stages. And quite frankly, the XSF is also not in any position to do so.
Just because a XEP is rejected, does not automatically mean that it will
not get implemented. The developers and users of XMPP software also
weight in and have an impact on the resulting ecosystem.
Therefore, I suggest that the XSF embraces competition in the early
stages and, in case of duplicated efforts, limits itself to advocating
certain extensions.
Equally, I've seen other proposals suggesting much
higher bars for
accepting a protoXEP, with in effect a pre-Experimental stage tacked on
beforehand. I think this would be bad, too, and risks just accreting
stages for no real benefit - but it's also essentially inevitable if the
bar for accepting a protoXEP is raised too high.
Such a pre-experimental stage already exists, whether we like it or not.
People work on XMPP extensions, and if the bar is too high, they will
just work on those extensions outside of the XSF [1].
And that is really a pity and something we should fix.
What I'd like to see is that the XSF creates a place to cater for those
ProtoXEPs (as how I will refer to pre-experimental XEPs in the
following). Could be as simple as creating a directory protoxeps/ in
xsf.git and ensuring that the contents of this directory rendered and
available under xmpp.org/extensions/protoxeps. I hope that this will get
us a long way towards fighting the fragmentation that we have [2].
We should make it crystal clear to readers of those ProtoXEPs that they
did not undergo any expert review yet. As consequence, this means that
the authors of those ProtoXEPs must be aware that it is not impossible
that their specification may need a major overhaul before it can enter
the 'experimental' stage [3]. In exchange, ProtoXEP may break their wire
protocol without a namespace bump (which must also clearly documented).
Consequently, this means that Council should focus on the technical side
when presented with a ProtoXEP for adoption. With a particular focus on
how idiomatic the XEP, when it comes to XMPP. For example, is there an
attribute when it should be an element?
And once a XEP has been honored with an number. Strict namespace
versioning rules should apply. Interoperability is a valuable asset in
XMPP land, that we must protect.
Last but not least and not directly related to strict namespace
versioning rules, but related to namespacing: I started to wonder if it
were not better if we requiring a new XEP number in case of a namespace
bump.
This would help when referencing XEPs. For example, if I would task some
random stranger to implement xep384, I would probably not end up with
the implementation that I wanted.
- Flow
1: This happened plenty of times, for example the various MUC
alternatives (MUCLight, MucSub, etc.)
2. XMPP extensions residing on personal homepages and/or personal gits
3: A recent example for this was Guus' "PubSub Server Information"
(xep485): At first reluctant, since there was already an implementation,
Guus could be convinced that the wire protocol and XML design should be
improved for the greater benefit.