-
flow
debacle, i'd probably simply mimic the pattern of xep335 for csv and init 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
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) ✏
-
debacle
flow OK, sounds good. In my case there will be only one payload, so this is easy.
-
pep.
Don't forget to namespace :)
-
debacle
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"?
-
jonas’
debacle, you could also go with standard <body/> and set Content-Type via XEP-0131
-
Kev
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.
-
Kev
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.
-
Kev
*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.
-
jonas’
that’s true
-
pep.
So the obvious solution is to convert everything to JSON and use 335!
-
Kev
...it's less bad than shoving things in the body :)
-
jonas’
noooooooooooo
-
pep.
:D
-
pep.
debacle: I imagine you use slix? it's quite easy to create a custom container based on the 335 module
-
pep.
Change the NS, the tag name and you're almost done
-
pep.
you can even do validation directly in there if you want
-
pep.
(just as the 335 slix module does)
-
flow
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
-
debacle
pep. libstrophe! ;-)
-
MattJ
The problem is that CSV is a terrible idea for interop
-
debacle
Not much worse than JSON ;-)
-
MattJ
JSON at least has just the RFC and the version everyone uses
-
debacle
RFC 4180. But anyway, this is about legacy/proprietary applications. It's not the scope of XMPP to fix them, I assume.
-
Kev
It's 432 I was thinking of, thanks flow.
-
MattJ
Honestly best to just use a custom element in a custom namespace
-
Kev
^
-
MattJ
I was going to ask about 432 recently
-
pep.
I still don't get 432 :/
-
pep.
Why..
-
debacle
kev MattJ I see. At least, that is easy.
-
MattJ
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
-
pep.
Yo dawg I know you like containers so I put a container in your container
-
MattJ
Is it needed? Or better to add these to JSON containers?
-
MattJ
The original UDT was too specific and extensive, but the current XEP doesn't seem so
-
pep.
funnily the shortname is still udt
-
debacle
OK, I will combine 0295 and 0335 then ;-) <json xmlns="urn:xmpp:json:0"> { "type": "text/csv", "data": "Aaron,Titus Andronicus..." } </json>
-
pep.
:x
-
pep.
Why
-
debacle
(kidding)
-
pep.
Ah sorry..
-
flow
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
-
flow
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
-
flow
so I see a certain appeal in that
-
jonas’
the textual data? ITYM CDATA or JSON data
-
jonas’
(and even CDATA I would find confusing, because the point would be to take JSON, not strings, via the API)
-
flow
hmm? textual data / char data, should be the same here
-
flow
on the xmpp library api surface it's just strings/textual data/character data
-
jonas’
I sure hope not
-
flow
if the string is json, csv, or whatever does not matter to the string representation
-
jonas’
then it’s no gain
-
pep.
flow, and that would already be out of spec for 432 as I understand it
-
jonas’
on the API surface it should be JSON
-
flow
pep., yes, iirc the first version of the protoxep for xep432 was different
-
flow
that UDT (?) thingy
-
pep.
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
-
flow
that would allow your library to provider 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
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") ✏
-
jonas’
flow, but not in '432
-
flow
jonas’, I know, I think that was one goal of UDT
-
jonas’
ok
-
flow
pep., again, that strikes me as something that does not exclude each other
-
flow
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
-
flow
I was that involved in UDT, but I think I liked the idea. not sure why it got cut down to json only✎ -
flow
I was not that involved in UDT, but I think I liked the idea. not sure why it got cut down to json only ✏
-
debacle
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"> {"foo":123} </json> </item> </publish> </pubsub> </iq> It works well, at least, but that does not mean anything.
-
jonas’
lgtm, but I always get confused by pubsub nesting
-
debacle
jonas’ That's why I ask ;-) But it seems things end up in PEP as intended.
-
jonas’
then it’s probably ok :)
-
rion
If anyone uses QCA for cryptography, I just added DTLS support there. So basically ready for Jingle stuff.
-
Zash
/react najs!
-
jonas’
react.js?
-
Zash
I'd rather not