On Donnerstag, 4. April 2019 12:52:15 CEST Florian Schmaus wrote: > On 02.04.19 10:07, Evgeny wrote: > > On Mon, Apr 1, 2019 at 9:40 PM, Florian Schmaus <f...@geekplace.eu> wrote: > >> I am a little bit worried that this will take a few detours to implement > >> cleanly and elegant in clients and client libraries. Especially since > >> this pattern never occurred before. > >> > >> Instead I suggest the following control flow, which should be straight > > > >> forward to implement with the facilities libraries currently provide: > > Hi, Florian, thanks for your feedback. > > Interestingly, in my very rough version I had exactly this scheme, and I > > found no real advantage. > > Is it possible that you looked at it with your XMPP server developer > googles on? :) > > > Instead, I made it possible to just resend the > > request (with the same CertificateRequest structure) if a client > > believes the challenge is resolved. > > So XEP-0417 specifies that upon solving the challenge I have to resend > the IQ request? I could not tell that this is the case, as you can see > from how I modelled the anticipated current protocol flow in my previous > message and below. Nevertheless I still would favour my suggested > protocol flow. > > > What "detours" do you see possible > > from a client developer perspective? > > Assume that most client libraries provide a facility to send a IQ > request, gather the response, or bail out on a timeout, and ensures that > no resources leak. The following should be considered pseudocode but > roughly reassembles Smack's API and thus may remember you of Java.
I agree with Florian fully. This is rather non-idiomatic to implement on the client side, due to how XMPP works otherwise. The flow suggested by Florian is more idiomatic and implementable with less brain-hurt. I don’t see any advantage (only disadvantages) on the client side with the message based flow (also, the horrors of carbons and archives), and I’m not sure which advantages there would be for servers. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
