22 Mar
2024
22 Mar
'24
6:10 a.m.
It's been pointed out to me that this comes across combative, which isn't
the intention, and I apologise for that.
The crux of my argument here is in the phrase "there's no common behaviour
between Features and, say, a '198 ack".
Much of the aims of XEP-0360 appear to be based on a desire to split top
level elements into things that are Stanzas, and things that are not. This
much is fine. The problem is that this alone does not warrant a XEP in my
view. The XEP then goes further by trying to document common features of
thing that are not Stanzas, but the only commonality around behaviours and
syntax of things that are not Stanzas is simply that they are not Stanzas.
It's a bit like trying to divide life into Plants, and things that are not
Plants. The division might well be useful, but it does not follow that the
things that are not Plants are all the same, somehow - the only commonality
ends up being that they're not Plants.
Imposing rules, however well-meaning, suggests a commonality that does not
exist.
The XEP is tripping over itself in trying to do demonstrate this
commonality. Section 3 suggests examples from other XEPs which don't use
the term. Section 4 suggests consistent behaviours that don't always apply.
Section 5 describes rules for interoperability which are either broken by
existing XEPs or essentially impossible to break.
Paradoxically, the XEP does highlight one issue, albeit obliquely - there
isn't actually a very good definition of "Stanza" anywhere. The XEP points
at two different sections of RFC 6120, but as others have pointed out,
XEP-0114 has something to say here too, and RFC 6120 points to RFC 6121 as
well for some behaviours. This of course causes a lot of complications in
Section 2. An informational XEP summarizing the definition and nature of
Stanzas would be very useful, I think, to newcomers and old hands alike. I
think we all kind of know what we mean when we say "Stanza", but I think
there's a lot of detail that would be useful to gather into one place.
Dave.
On Fri, 22 Mar 2024 at 10:40, Dave Cridland <dave(a)cridland.net> wrote:
On Fri, 22 Mar 2024 at 08:47, Florian Schmaus <flo(a)geekplace.eu> wrote:
For example, assume a XMPP library written in an
object-oriented
language. There is a superclass TopLevelStreamElement which has one
obvious subclass named Stanza. Now, how should we name the other
subclass? TopLevelElementThatIsNotAStanza? Feels ridiculous.
Well, now, that's a really interesting question that delves into OOP
design.
So, if you're of the classical Java bent, and therefore like injecting
class hierarchies into everything, you'd have (and I write this in C++,
because, well, reasons):
class TopLevelElement;
class Stanza public TopLevelElement;
class Message public Stanza;
class Presence public Stanza;
OK, so this seems fair - Messages and Presences are both Stanzas, which is
a TLE. Great! So what about a stream:features element?
class Features public TopLevelElement;
Well, it's a TLE, but it's not a Stanza.
The thing is, Messages, Presences, and IQs all have common behaviour which
is sensibly encapsulated into a Stanza class (if we're doing classical OOP,
anyway).
But there's no common behaviour between Features and, say, a '198 ack -
there's nothing that is needed there.
Now, you might want to do polymorphism based on something that's not a
Stanza - I can't actually think why - and for that you might want to inject
an artificial class. But this is an implementation detail, not something to
foist upon the entire community.
Dave.