SamMessages 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?
SamI'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
SamHaving 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.
moparisthebestmy gut feeling is that belongs higher in the stack, so that the user can always get at the raw XML
moparisthebestbut since I know nothing about your library you should take that with a hefty grain of salt
Samyah, I have the same feeling. I can't think of any reason why that would be the case though.
SamAnd the raw xml is already lost, my xml library doesn't preserve it
moparisthebestoh, well if that's the case then maybe doesn't matter
moparisthebestfrom 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"
Sameg. <a/> and <a></a> are indistinguishable.
J Marinarohas left
J Marinarohas joined
J Marinarohas left
SamTried 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.
SamIf 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)
SamIf 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.
SamSo 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.
moparisthebestis there a list of shame anywhere of all the TLDs that don't support DNSSEC ?
SamNot specifically a list of shame but https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains has all the info
moparisthebest...but can I parse it with grep >_> <_< thanks Sam !