jdev - 2020-09-01

debacle, i'd probably simply mimic the pattern of xep335 for csv and ini files, and i'd potentially add an 'id' attribute to the element, which identifies the payload in case there are multiple payloads of the same kind (akin to data form's FORM_FIELD, but not within the payload) ✏

flow OK, sounds good. In my case there will be only one payload, so this is easy.

Don't forget to namespace :)

MattJ Why does a container for JSON exist, but not for other text types? Does "XEP-1521: Text Containers" make sense? <text xmlns="urn:xmpp:text:0" type="text/csv"> Aaron,Titus Andronicus The Abbott of Westminster,Richard II Lord Abergavenny,Henry VIII </text> With type = (whatever boils down to text in the MIME universe), maybe defaulting to "text/plain"? Or would people start to use it for multipart "application/vnd.ms-powerpoint"?

debacle, you could also go with standard <body/> and set Content-Type via XEP-0131

debacle: The reason for JSON containers was that lots of people shove things in body that really shouldn't be there, and it's usually JSON.

And there was a hope that by providing a XEP, libraries would support it and it would be as easy to do something that was less wrong as it was to do the wrong thing.

*really* the sensible thing to do is to use your own element in your own namespace when shifting stuff around that's only understood by your own application.

that’s true

So the obvious solution is to convert everything to JSON and use 335!

...it's less bad than shoving things in the body :)

noooooooooooo

:D

debacle: I imagine you use slix? it's quite easy to create a custom container based on the 335 module

Change the NS, the tag name and you're almost done

you can even do validation directly in there if you want

(just as the 335 slix module does)

there's also xep432, but it's specific to json. I do wonder, just like debacle, if this shouldn't be applied to other text types

pep. libstrophe! ;-)

The problem is that CSV is a terrible idea for interop

Not much worse than JSON ;-)

JSON at least has just the RFC and the version everyone uses

RFC 4180. But anyway, this is about legacy/proprietary applications. It's not the scope of XMPP to fix them, I assume.

It's 432 I was thinking of, thanks flow.

Honestly best to just use a custom element in a custom namespace

^

I was going to ask about 432 recently

I still don't get 432 :/

Why..

kev MattJ I see. At least, that is easy.

It's renamed and vastly simplified (I approve), but now it's just a wrapper around JSON containers that adds a datatype field and disco

Yo dawg I know you like containers so I put a container in your container

Is it needed? Or better to add these to JSON containers?

The original UDT was too specific and extensive, but the current XEP doesn't seem so

funnily the shortname is still udt

OK, I will combine 0295 and 0335 then ;-) <json xmlns="urn:xmpp:json:0"> { "type": "text/csv", "data": "Aaron,Titus Andronicus..." } </json>

:x

Why

(kidding)

Ah sorry..

pep.> I still don't get 432 :/ I think the idea was that xmpp client libraries provide a common API to get/set the textual data

compared to custom elements, this would have the advantage that you don't need to fidle with whatever you need to do to plug support for those custom elements into the library you are using

so I see a certain appeal in that

the textual data? ITYM CDATA or JSON data

(and even CDATA I would find confusing, because the point would be to take JSON, not strings, via the API)

hmm? textual data / char data, should be the same here

on the xmpp library api surface it's just strings/textual data/character data

I sure hope not

if the string is json, csv, or whatever does not matter to the string representation

then it’s no gain

flow, and that would already be out of spec for 432 as I understand it

on the API surface it should be JSON

pep., yes, iirc the first version of the protoxep for xep432 was different

that UDT (?) thingy

I'd rather teach devs how to use the library rather than having them use a one-size-fits-all thing that doesn't fit all

that would allow your library to provide setters/getters like setter: setPayload(Stanza stanza, Type type, String id, String payload) → setPayload(stanza, Type.CSV, "my-data", "foo, bar, baz") getter: String getPayload(Stanza stanza, Type type, String id) → getPayload(stanza, Type.CSV, "my-data") ✏

flow, but not in '432

jonas’, I know, I think that was one goal of UDT

ok

pep., again, that strikes me as something that does not exclude each other

Smack has had JiveProperties since nearly 20 years now, and from what I can tell it is very well accepted by the users, as it allows to transport arbitrary data easily, without having to fiddle with adding custom extension elements

I was not that involved in UDT, but I think I liked the idea. not sure why it got cut down to json only ✏

Btw. I wonder, whether this structure is correct? <iq id="1" type="set"> <pubsub xmlns="http://jabber.org/protocol/pubsub"> <publish node="mynode"> <item> <json xmlns="urn:xmpp:json:0"> {&quot;foo&quot;:123} </json> </item> </publish> </pubsub> </iq> It works well, at least, but that does not mean anything.

lgtm, but I always get confused by pubsub nesting

jonas’ That's why I ask ;-) But it seems things end up in PEP as intended.

then it’s probably ok :)

If anyone uses QCA for cryptography, I just added DTLS support there. So basically ready for Jingle stuff.

/react najs!

react.js?

I'd rather not