[Standards] Proposed XMPP Extension: User-defined Data Transfer
dave at cridland.net
Tue Dec 31 12:47:43 UTC 2019
On Tue, 31 Dec 2019 at 01:39, Marvin W <xmpp at larma.de> wrote:
> 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
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='user at example.org' to='other at example.org' type='chat'
<body>Hey, this is a message!</body>
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
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
> Also I wonder why:
> <message [...]>
> <payload xmlns="urn:xmpp:udt:0" datatype="urn:example:foo">
> <json [...] />
> is considered superior to:
> <message [...]>
> <x xmlns="urn:example:foo">
> <json [...] />
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
> Also a small formal issue: the XEP does say that it requires no XMPP
> registrar considerations, however it introduces a new namespace
If it gets vetoed for that I'm at a loss as to what would ever get
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards