As soon as tools get into accessing resources via URLs from the XML (which I don't think is what you're doing, but it might be the next step for someone), it should be documented that there's a need for access control.
Sorry, I mostly meant to make a side comment for the list, and I overstated a little.
When we're developing tools that can have URIs within the XML that reference external resources, and we or other layered code might make requests for those URIs, we should be cautious. Maybe it's also appropriate to document the delicate nature, even if our code layer itself is not vulnerable, since there are a lot of bad practices right now, and I think there's a need for remedial education.
ENGINEER: "Of course, in the real-world practice, no one could manage to do this insecurely."
WEBROGRAMMER: "Hold my Red Bull..." :)
Honestly, I don’t really think that this package should have anything to do with resolving URIs; I’m tempted to redesign it in such a way that it accepts as an argument a function used to deal with the whole URI side of the world. Units, anyone?
Regarding units, if there's a problem to solve in code, and it can be done in the reusing API as closure optional keyword arguments, rather than as a units&sigs, I think the former is much easier for a reusing programmer. (Units are a good idea for some purposes, but are not something many Racket programmers have ever had to use, so I think the payoff for mandating units for a given purpose should be big. That said, newer Racket features, like submodules (and TR?), combined with a little syntactic sugar, could make units less of a bureaucratic burden to use than they were originally.)
-- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
