jdev - 2023-01-14

  1. Zash

    Did it like that in the Prosody error wrapper library, which tries to be somewhat ignorant of XML. The application-specific condition can be a tuple (condition, namespace) or a single XML element.

  2. stpeter

    @Sam AFAIK, we've never defined an application-specific error condition that employs more than one child element of <error/>. IMHO conceptually that wouldn't be sensible, since it is a particular component (e.g., MUC) or code module (e.g., disco) that generates the application-specific condition - basically that piece of code further clarifies specifically why it's a bad-request error or whatever.

  3. stpeter

    (It wouldn't make sense for the MUC module to say "here's why I think it's a bad request" and for the disco to offer its own independent reason why it's a bad request, as it were...) ✎

  4. stpeter

    (It wouldn't make sense for the MUC module to say "here's why I think it's a bad request" and for the disco module to offer its own independent reason why it's a bad request, as it were...) ✏

  5. Zash

    PubSub uses some application-specific conditions. One could imagine an application using PubSub for something wanting to be even more specific in its errors.

  6. stpeter

    nod

  7. Sam

    Thanks all; makes sense.

  8. Zash

    Reminds me of my unfinished XEP about s2s error conditions.

  9. Zash

    Given how uncommon application-specific conditions are, seems a bit hard to justify adding support for unlimited numbers of them...

  10. Beherit

    Hello everyone, very last call for XMPP projects to submit their ideas and participation interest: https://wiki.xmpp.org/web/Google_Summer_of_Code_2023#Project_Ideas_(TO_BE_UPDATED_FOR_2023)