XSF Discussion - 2020-01-01

Daniel, Not an elaborate joke. It's trying to provide a safe middle ground between "Stuff JSON in <body/>" and "Write your own extension", and the need is based very firmly on evidence from multiple cases of people outside this community trying to use our product and failing.

Daniel, So yeah, it sucks, but it sucks less than what people do now.

dwd, isn't the answer "teach these devs that XML is extensible"?

pep., How?

I don't know, just say that

"XML is extensible"

pep., Genuine question. Because whatever we're doing now isn't working. Most of the examples I've been told are in confidence, but I can be quite open about how my employer used (and misused) XMPP before I came along.

I really don't see the point of this XEP

Maybe what we need is dev docs, not weird extensions

pep., Did you read the thread between me and Marvin?

yes

(admittedly I'm still a walking zombie from CCC-induced sleep depravation)

dwd, your argument was, xmpp libs provide set_body() set_subject(), but not set_my_random_extension()

correct me if im wrong

pep., OK. I can assure you that the folks who worked on our app aren't stupid, do read docs, and so on. But they also thought the simplest and fastest way to get custom messages into XMPP was to stuff JSON into the body tag.

lovetox, Not quite. My argument was that people do this stuff. My proposed solution is that we give them a very very low friction path to doing something slightly less sucky.

dwd, and you assume they'll find this new XEP just like they found the hundreds of others that were using custom elements? :)

pep. they find the docs of the xmpp libs

and the xmpp lib, provides, set_custom_json_payload

or something

pep, Nope, which is why I think that for success, it needs to be a recognisable API in libraries.

because it implements the xep

lovetox, That, yes.

Well you can have a library provide this API without actually having a XEP for it. It's all non-standard anyway

pep., But the library's implementation needs to be interoperable with another's.

i understand what you are trying to say, but this seems all very werid, we seem to talk about developers that totally ignore what xml is and how it can be used

lovetox, Yes. Exactly.

and there is no xmpp lib in the world that does not have a api to add a node under body

lovetox, Give me 100 developers, and we'll find maybe one that understands basic XML.

not under body, under message i meant

really? ok im not in the software dev industry, so i dont have experience what devs know usually

lovetox, Sure, we could stuff in a generic element maybe. Though the API radically changes between libraries, and listening for it would also change.

lovetox, Developers tend to understand JSON - they get the exposure. Very few people use XML these days.

ah, yeah thats a better point :)

so basically you could use these libs and xmpp, without knowing a single thing about xml

lovetox, Yeah, that's the idea.

lovetox, You can already, mind, it's just that for these custom cases you tend to make design choices that suck later.

lovetox, Like we did. ALso other cases that I know you've heard of but I was told in confidence.

I remember quite clearly my experience first building things in XMPP. I stuffed json payloads in messages because I could do _that_ in the first days before really figuring out what exactly an IQ stanza is, etc. And even more, I could use my existing IM client as a 'console' of sorts to act as a REPL without needing to build something custom.

yeah i understand, if they want to extend xmpp, they suddenly need someone who knows his shit about xmpp

lovetox, Oh, no. It's worse than that.

for us its quite natural to just add a node under message and say we extended with a custom element

lovetox, They extend XMPP just fine, but they do so in a way that isn't sustainable.

but coming with no expierience, i wouldnt know if this is allowed, i would need to read the xmpp standard

lovetox, RIght - anyone who ever reads that XEP is not the target audience for the API. :-)

yeah gottcha :)

dwd, do you actually need library compatibility? I mean, why not, but this proprietary protocol that unknowing devs created would probably be used only internally. If they want to expose that then maybe they'd think twice.

I thought I was thinking application devs shouldn't be required XMPP knowledge, but maybe it's time for me to revisit the idea. This XEP just feels wrong

pep., Library compatibility for UDT? Sure. We use two entirely different XMPP libs in our case - Smack and XMPPFramework. If these don't provide a similarish API to do this then people will just carry on what they're doing - stuffing JSON into body and wrecking the extensibility.

pep., I mean, you could also do a meta-extension like Marvin suggests, but I think that's harder to specify, and you definitely couldn't do XPath.

pep., Oh, and the XEP *is* wrong. For you, for me, and for anyone else that reads it.

Also, why only JSON

What about all other serialization formats

Do I need to define another udt

i think json is just an example

Isn't the problem that libraries don't make it easy and obvious how to create extensions?

For example I find babbler does a good job and explaining fairly early on in its documentation how to do that

And if the xeps goal is to change libraries. Can we not just have them do that

yes if every library adds a set_custom_extension() method, this would serv the same purpose

but libs tend to implement XEPs

but yeah actually no lib that i know has this

Slixmpp allows the user to define new extensions by using classes. Might not be perfect and possibly confusing, but that's one way to do it

(Well, sleekxmpp allowed*)

funny, im using a xmpp lib, and it gives me no method or api to Extend the extensible protocol

only XML api

and i use a xmpp lib to abstract the XML stuff away in the first place

FWIW, later work on our codebase added custom XML elements. This stuff can be done (and I like the way Sl*XMPP does in=t in Python myself).

Oh, UDT picks JSON because that'd cover everyone. Anyone who feels strongly enough to do something other than JSON would be willing to dig into the library and extend it properly.

"JSON is enough for everyone" ✏

Careful not to copy bill gates too much.