jdev - 2022-02-28


  1. Sam

    Messages with any type that's not one of the defined ones (including a missing attribute) default to type="normal". Is there any reason why I'd ever need to distinguish between type="" and type="normal" even though technically they're the same thing?

  2. Sam

    I'm debating whether it's better to unmarshal XML with type="" into "Type: 'normal'" in the struct I'm using or if it's better to leave the struct with the wire value and only consider an empty attribute to be "normal" when doing any sort of pattern matching on the stanza

  3. Sam

    Having the user be able to do a naive comparison "msg.Type == 'normal'" would be nice, but I have a vague feeling I'll want the wire value at some point for some reason.

  4. moparisthebest

    my gut feeling is that belongs higher in the stack, so that the user can always get at the raw XML

  5. moparisthebest

    but since I know nothing about your library you should take that with a hefty grain of salt

  6. qy

    https://xmpp.xa0.uk:5281/upload/azCIolN6-Zwc4coQ/DyqponZW0AEtL8L.jpg

  7. qy

    (is it still really a grain at that point?)

  8. moparisthebest

    everything is relative!

  9. Sam

    yah, I have the same feeling. I can't think of any reason why that would be the case though.

  10. Sam

    And the raw xml is already lost, my xml library doesn't preserve it

  11. moparisthebest

    oh, well if that's the case then maybe doesn't matter

  12. moparisthebest

    from a debugging POV, it's rough if you say "hey I think your client/server has a bug, but since I can't see the raw xml, it might be my bug"

  13. Sam

    eg. <a/> and <a></a> are indistinguishable.

  14. Sam

    Tried to write up all the possible solutions I could think of, and I think I've convinced myself that just doing it at the wire boundary is the best solution.

  15. Sam

    If we do it during pattern matching it has the issues I already mentioned (plus our stanza matching is modular, users can pull it out and use their own xpath based version, for example, if they wanted and they'd have to know to reimplement this logic there)

  16. Sam

    If we do something like give messages a TypeAttr() method that returns the normalized type attribute we can compare against that, and still have the original value preserved, but it creates a weird side channel where we decode a message with type="someinfo" and then if we use the same message struct and forward it somewhere else for some reason we send whatever invalid type attribute got sent to us. That feels like some sort of privacy issue waiting to happen.

  17. Sam

    So maybe just normalizing it when it comes in or goes out over the wire keeps things simple. We won't be able to interface with broken implementations that use their own custom type attributes (and I'd bet those exist), but I'm not sure how important that is.

  18. moparisthebest

    is there a list of shame anywhere of all the TLDs that don't support DNSSEC ?

  19. Sam

    Not specifically a list of shame but https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains has all the info

  20. moparisthebest

    ...but can I parse it with grep >_> <_< thanks Sam !