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 <d...@cridland.net> wrote: > > > On Fri, 22 Mar 2024 at 08:47, Florian Schmaus <f...@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. >
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
