On Tue, 31 Dec 2019 at 01:39, Marvin W <x...@larma.de> wrote: > Hi, > > I'd like to express my concern that the purpose of this proposed XEP is > mostly around defining a specific API to library developers. According > to XEP-0001, a Standards Track XEP defines a *wire protocol* intended to > be used as a standard part of XMPP technologies. Nothing indicates that > a XEP shall define library APIs. > > Yes, it is defining a specific API and, from there, a very simple wire protocol.
This is very much an unusual idea for the XSF, and I don't dispute it's outside our normal remit - though we're not prohibited from this either. I have absolutely no doubt that you (or, indeed, anyone reading this mail) could design a better protocol for any use that this will be put to in your sleep. It is not intended to be the best way of exchanging custom messages etc. It's merely intended as being a very simple way that's not actively causing harm, that a developer new to XMPP can immediately start using, and won't have cause to regret later. Let me give you a specific example. I hope you're sitting down. My employer switched to XMPP some time ago (before I joined). We exchange messages of various types - some of these are things like replies, which one could probably do in an XMPPish way if one had our experience. Some are things which definitely could be - sending images, for example. Some are entirely new, like closing tissue viability queries. The solution the development team picked was to send these all as blobs of (usually) JSON (except the original plain text messages), and then use the subject field (which was available in the API) to indicate the type. This means a plain text message looks like this: <message from='u...@example.org' to='ot...@example.org' type='chat' id='xyz123'> <subject>text/plain</subject> <body>Hey, this is a message!</body> </message> Other message types have a different subject string and a different body - it's usually, but not always, a JSON blob. I can't fault it for expediency. The alternative would have been to develop complex custom XML code in libraries new to them for protocols new to them and do so fast enough to satisfy the demands of a very fast moving market - the switch to XMPP took long enough, had it taken longer, it'd have likely been dropped. I cannot fault the development team for choosing this route. The problem is that - and I appreciate you've seen this already - it's almost impossible to switch away from this to something more advanced and idiomatically correct. I thought that perhaps it was only our development team who were, in effect, forced down this route, but after discussing it with various people, I've found this is a very common pattern outside our bubble. When a new development team picks up XMPP, this seems to be what people do - it's far easier and a far shallower learning curve than doing things properly. So therefore, in order to make things easier for developers, this approach seems warranted. Had this protocol (or something similar) existed, and had there been an API available for it in the libraries we use (Smack and XMPPFramework, by the way), then we'd have used it from the outset - it'd have been an absolute no-brainer. No doubt I'd have still come along and said "Oh, hey, we can improve this and make it more interoperable", but there'd be a clear path for us to do so. Instead, I've got a lot of complex work to do to "fix" something that's fundamentally working. > Also I wonder why: > > <message [...]> > <payload xmlns="urn:xmpp:udt:0" datatype="urn:example:foo"> > <json [...] /> > </payload> > </message> > > is considered superior to: > > <message [...]> > <x xmlns="urn:example:foo"> > <json [...] /> > </x> > </message> > > You absolutely could, of course. But I don't think that'd be easier to manage inside a library, and moreover, it'd be more difficult to specify via schemas and things. > The whole proposed XEP seem to create a wire protocol for the needs of a > specific library design. For example > udt_message_callback(session, datatype, callback) could also be realized > using message_callback(session, xpath, callback) without requiring a new > wire protocol. > Oh, sure. I'm unconvinced that would be used, because XPath. But yes, one could design it this way and you'd end up with a better (in terms of idiomatic XMPP) protocol. That's not the goal here, though - the goal is to get a generalized framework that's the lowest barrier to entry we can get without causing actual harm. > Also a small formal issue: the XEP does say that it requires no XMPP > registrar considerations, however it introduces a new namespace > "urn:xmpp:udt:0". > > If it gets vetoed for that I'm at a loss as to what would ever get accepted. :-) Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
