On 24 Sep 2019, at 16:42, Dave Cridland <[email protected]> wrote: > > > > On Tue, 24 Sep 2019 at 09:30, Kevin Smith <[email protected] > <mailto:[email protected]>> wrote: > On 24 Sep 2019, at 09:20, Dave Cridland <[email protected] > <mailto:[email protected]>> wrote: > > > > 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. > > It’d depend how wed you are to exactly what you describe there. Swiften’s API > would make more sense to do message->setSadexType(…) and > message->setSadexData(), and a callback wouldn’t make much sense, you’d just > message->getSadexType and message->getSadexData() (or maybe > message->getSadex()->(get|set)(Data|Type)(). Not what you describe, but still > equivalent to how subject/body work in the API, and I don’t see a problem > with adding it. > > I think we're looking at a type (something morally equivalent to an XML > namespace) and payload, and we want to ensure both are set or neither.
I’m assuming you mean ensuring on the send side, rather than receive? e.g. you’re not anticipating a library auto-errorring stanzas with one and not the other. > But you're absolutely right that whatever API is used should fit the existing > APIs of the library. > > But ultimately, I'm most interested in a low-friction way of exchanging > application-specific data that will guide people away from doing worse > things. The constraints here would seem to be "easy to use", "obvious", and > probably "in the core/default download”. I see no problem doing that in Swiften. /K
_______________________________________________ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
