ZashXEP-0215 client implementers, do you implemente the <credentials/> thing at all?
MartinForwarded to conversations muc.
Zashthx
MartinZash:
> i don’t use credentials
From Daniel
ZashMhm
HolgerPhilipp tried to explain on the list but I still don't get the point of the seperate `<credentials/>` request.
ZashImagine handing out a HTTP Upload slot in every disco#info. That's what it does.
HolgerDunno the XEP is a super-trivial request-response thing plus two different syntaxes to allow the client to filter the response list; neither of which allow the client to query just the single service it wants.
Luciolehas left
Luciolehas joined
kikuchiyohas left
ZashI don't see a generic implementation of 215 working this way.
HolgerAt the same time a single tag (`<services/>`) has different syntax depending on whether it's used in the request or the response so you can't properly schema-validate it.
HolgerZash, generic implementation of 215 working what way?
ZashHolger: More like how mod_disco in prosody works, with other modules adding 'items' (features, identities, stuff) and then mod_disco composes replies from that.
HolgerAh, right.
ZashGets awkward if those items are supposed to be dynamic.
HolgerAh there's also the push support of course.
ZashThe <credentials/> lets you limit your dynamicness
ZashThe <credentials/> query lets you limit your dynamicness
ZashAnd if it's something where it's expensive to produce those crendentials you don't wanna do that a lot just becasue the client wants to know what's available.
HolgerHeh, ok.
HolgerI implemented the `<credentials/>` thing anyway, glad to hear a reasoning why that might make sense 🙂
pep."Holger> At the same time a single tag (`<services/>`) has different syntax depending on whether it's used in the request or the response so you can't properly schema-validate it." not in the xml schema for sure (and I also find this meh) but you can have a In/Out Receiver/Sender foo/bar structure in the code for sure
ZashOr we might as well rename 215 "TURN/STUN query protocol" and drop the genericness
Holgerpep., yeah. My XMPP library doesn't.
pep."Holger> At the same time a single tag (`<services/>`) has different syntax depending on whether it's used in the request or the response so you can't properly schema-validate it." not in the xml schema (and I also find this meh) but you can have a In/Out Receiver/Sender foo/bar structure in the code for sure
kikuchiyohas joined
HolgerMy library mostly just does (de)serialization based on XML-schema-like schemas. I can't tell it about in/out.
HolgerZash, I think 0215 originally was STUN/TURN-specific and then switched to genericness.
pep.I would love for mine to do that but unfortunately it's not possible as schemas are (first not normative ?!?! but also) not always how you'd like to structure data :/
pep.I think there's the same issue for <bind/>
pep.and maybe others
HolgerWell it's just schema-like-schema 🙂 We invented our own thing to describe XMPP syntax.
ZashWell then why is http upload its own completely separate thing?
HolgerBut issues such as the `<services/>` thing are the same for us as for standard XML schema.
ZashOne of these days I might have to invent one of those too
ZashSchema / data mapping thingymajigger
HolgerI now gotta check syntax within the query handling code rather than in the deserialization layer.
ZashSeparation of syntax and semantics checking might be sensible tho?
Holger> Well then why is http upload its own completely separate thing?
Good question.
jdevhas left
pep.Holger, re bind:
BindQuery: https://gitlab.com/xmpp-rs/xmpp-rs/-/blob/master/xmpp-parsers/src/bind.rs#L15
BindResponse: https://gitlab.com/xmpp-rs/xmpp-rs/-/blob/master/xmpp-parsers/src/bind.rs#L73