dwdDaniel, 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.
dwdDaniel, So yeah, it sucks, but it sucks less than what people do now.
pep.dwd, isn't the answer "teach these devs that XML is extensible"?
pep.I don't know, just say that
pep."XML is extensible"
dwdpep., 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.
pep.I really don't see the point of this XEP
pep.Maybe what we need is dev docs, not weird extensions
dwdpep., Did you read the thread between me and Marvin?
pep.(admittedly I'm still a walking zombie from CCC-induced sleep depravation)
lovetoxdwd, your argument was, xmpp libs provide set_body() set_subject(), but not set_my_random_extension()
lovetoxcorrect me if im wrong
dwdpep., 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.
dwdlovetox, 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.
pep.dwd, and you assume they'll find this new XEP just like they found the hundreds of others that were using custom elements? :)
lovetoxpep. they find the docs of the xmpp libs
lovetoxand the xmpp lib, provides, set_custom_json_payload
dwdpep, Nope, which is why I think that for success, it needs to be a recognisable API in libraries.
lovetoxbecause it implements the xep
dwdlovetox, That, yes.
pep.Well you can have a library provide this API without actually having a XEP for it. It's all non-standard anyway
dwdpep., But the library's implementation needs to be interoperable with another's.
lovetoxi 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
dwdlovetox, Yes. Exactly.
lovetoxand there is no xmpp lib in the world that does not have a api to add a node under body
dwdlovetox, Give me 100 developers, and we'll find maybe one that understands basic XML.
lovetoxnot under body, under message i meant
lovetoxreally? ok im not in the software dev industry, so i dont have experience what devs know usually
dwdlovetox, Sure, we could stuff in a generic element maybe. Though the API radically changes between libraries, and listening for it would also change.
dwdlovetox, Developers tend to understand JSON - they get the exposure. Very few people use XML these days.
lovetoxah, yeah thats a better point :)
lovetoxso basically you could use these libs and xmpp, without knowing a single thing about xml
dwdlovetox, Yeah, that's the idea.
dwdlovetox, You can already, mind, it's just that for these custom cases you tend to make design choices that suck later.
dwdlovetox, Like we did. ALso other cases that I know you've heard of but I was told in confidence.
LanceI 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.
lovetoxyeah i understand, if they want to extend xmpp, they suddenly need someone who knows his shit about xmpp
dwdlovetox, Oh, no. It's worse than that.
lovetoxfor us its quite natural to just add a node under message and say we extended with a custom element
dwdlovetox, They extend XMPP just fine, but they do so in a way that isn't sustainable.
lovetoxbut coming with no expierience, i wouldnt know if this is allowed, i would need to read the xmpp standard
dwdlovetox, RIght - anyone who ever reads that XEP is not the target audience for the API. :-)
lovetoxyeah gottcha :)
pep.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.
pep.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
dwdpep., 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.
dwdpep., 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.
dwdpep., Oh, and the XEP *is* wrong. For you, for me, and for anyone else that reads it.
pep.Also, why only JSON
pep.What about all other serialization formats
pep.Do I need to define another udt
lovetoxi think json is just an example
DanielIsn't the problem that libraries don't make it easy and obvious how to create extensions?
DanielFor example I find babbler does a good job and explaining fairly early on in its documentation how to do that
DanielAnd if the xeps goal is to change libraries. Can we not just have them do that
lovetoxyes if every library adds a set_custom_extension() method, this would serv the same purpose
lovetoxbut libs tend to implement XEPs
lovetoxbut yeah actually no lib that i know has this
pep.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
pep.(Well, sleekxmpp allowed*)
lovetoxfunny, im using a xmpp lib, and it gives me no method or api to Extend the extensible protocol
lovetoxonly XML api
lovetoxand i use a xmpp lib to abstract the XML stuff away in the first place
dwdFWIW, 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).
dwdOh, 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.