Simple Arbitrary Data Exchange

--===============0567964591==
Content-Type: multipart/alternative; boundary="00000000000058dcdc05934836ed"

--00000000000058dcdc05934836ed
Content-Type: text/plain; charset="UTF-8"

Morning all,

I've noticed in a number of places - both places I've worked and places I
know others - that were XMPP is used, there's often a desire to simply
exchange some private application data. Often, that data is in JSON, though
I imagine it occurs in XML sometimes too.

What unfortunately tends to happen is that the data gets stuffed into the
<body/>, and sometimes other "fields" of IM messages are abused in similar
ways.

In the concrete cases I've seen, <subject/> has been used to indicate a
message payload type, with the payload itself stuffed into <body/>. This is
clearly bad practise.

We (more or less) have the right tools for encapsulating JSON into XMPP, so
that is clearly not enough for newcomers to XMPP to make the "right"
decision. Instead, they're using existing, easy-to-use APIs in client
libraries to find a low-cost, pragmatic solution - but thereby painting
themselves into a corner in the long term.

Is there interest amongst the developer community to provide a generalised,
interoperable facility for the exchange of simple, arbitrary data between
consenting entities? I'm calling this SADEX, but I'm really, really, not
wed to this name.

The key here would be the API - you'd want to provide the equivalent of a
function call such as:

void sadex_message(JID to, String type, String data)

You'd also need a callback for when you receive some, and perhaps an IQ
form.

The wire format is pretty trivial, and largely uninteresting, but I'm happy
to sketch something out in a XEP if people want something concrete to work
against - but mostly I'd like to know if there's interest.

Dave.

--00000000000058dcdc05934836ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Morning all,<div><br></div><div>I&#39;ve noticed in a numb=
er of places - both places I&#39;ve worked and places I know others - that =
were XMPP is used, there&#39;s often a desire to simply exchange some priva=
te application data. Often, that data is in JSON, though I imagine it occur=
s in XML sometimes too.</div><div><br></div><div>What unfortunately tends t=
o happen is that the data gets stuffed into the &lt;body/&gt;, and sometime=
s other &quot;fields&quot; of IM messages are abused in similar ways.</div>=
<div><br></div><div>In the concrete cases I&#39;ve seen, &lt;subject/&gt; h=
as been used to indicate a message payload type, with the payload itself st=
uffed into &lt;body/&gt;. This is clearly bad practise.</div><div><br></div=
><div>We (more or less) have the right tools for encapsulating JSON into XM=
PP, so that is clearly not enough for newcomers to XMPP to make the &quot;r=
ight&quot; decision. Instead, they&#39;re using existing, easy-to-use APIs =
in client libraries to find a low-cost, pragmatic solution - but thereby pa=
inting themselves into a corner in the long term.</div><div><br></div><div>=
Is there interest amongst the developer community to provide a generalised,=
 interoperable facility for the exchange of simple, arbitrary data between =
consenting entities? I&#39;m calling this SADEX, but I&#39;m really, really=
, not wed to this name.</div><div><br></div><div>The key here would be the =
API - you&#39;d want to provide the equivalent of a function call such as:<=
/div><div><br></div><div>void sadex_message(JID to, String type, String dat=
a)</div><div><br></div><div>You&#39;d also need a callback for when you rec=
eive some, and perhaps an IQ form.</div><div><br></div><div>The wire format=
 is pretty trivial, and largely uninteresting, but I&#39;m happy to sketch =
something out in a XEP if people want something concrete to work against - =
but mostly I&#39;d like to know if there&#39;s interest.</div><div><br></di=
v><div>Dave.</div></div>

--00000000000058dcdc05934836ed--

--===============0567964591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
JDev mailing list
Info: https://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________

--===============0567964591==--