Excited to try this! Generating Atom and RSS feeds is on the to-do list for one of my current projects.
On Mon, Oct 25, 2021 at 10:25 PM 'Joel Dueck' wrote: > > - MIME types: Yes, I should use/add a more complete extension→type > mapping, though I probably will continue not to validate MIME types against > the IANA list. (My somewhat erroneous note in the docs notwithstanding, it > turns out having a non-IANA MIME type or a valid but mismatched type in an > enclosure doesn’t actually cause feed validation errors.) > > Since you have a dependency on `web-server-lib`, instead of shipping your own "mime.types", you can write: (define-runtime-path mime.types '(lib "web-server/default-web-root/mime.types")) to use the one it ships. It seems generally useful enough that maybe it should be split into a package like "web-server-mime-types-lib". I've been meaning for years to improve the file, and the general `make-path->mime-types` functionality, with some upstream database, perhaps the fairly comprehensive one at https://github.com/jshttp/mime-db (which pools data from Apache, Nginx, and IANA, and is used by e.g. Github Pages). > > - language-codes: yes this should be a value, not a procedure. Will > change it. > > `system-language` should use `delay/sync` to be safe for concurrent access. I'm not totally clear about all of the different sets of requirements (RSS, Atom, and, de facto, Apple), but I thought there were more language codes permitted than ISO 639-1 (e.g. https://www.rssboard.org/rss-language-codes points to ISO 639-2, and https://validator.w3.org/feed/docs/rfc4287.html#rfc.section.4.2.7.4 for Atom points to RFC 3066. These standards also allow for the assignment of new codes (and, at least for ISO 639-3, deprecation). I hope the right set of codes might be in the one of the CLDR packages (also used by Gregor): if so, I'd recommend getting it from there. > > - Removing dependencies: yes, I see the appeal. I’m really not eager > to reimplement all the timezone handling and temporal comparison stuff in > gregor, though. > > Please keep depending on Gregor! I think it's one of the treasures of the Racket library, and we should all just use it, as even the documentation for `racket/date` suggests <https://docs.racket-lang.org/reference/time.html#%28part._date-string%29>, rather than create any more, as Greenspun might put it, "ad hoc, informally-specified, bug-ridden, slow implementation[s] of half of" Gregor. On a different topic, for the XML stuff, is there a requirement that embedded HTML be represented with the CDATA lexical syntax? Under normal XML rules, this xexpr: `(content ,(cdata #f #f "<![CDATA[<div><p>Hi & < ></p></div>]]>")) should be semantically equivalent to this one: '(content "<div><p>Hi & < ></p></div>") which would generate the XML concrete syntax: <content><div><p>Hi & < ></p></div></content> This has the advantage of avoiding prohibition on `]]>` within CDATA concrete syntax, and it lets everyone manipulating these feeds in Racket avoid the need to add and remove "<!CDATA[" and "]]>" from the string inside the CDATA struct. (Tangentially, AIUI the convention is to use `#f` for the start and stop fields when creating cdata and p-i structures in code, though apparently the docs for `source` <https://docs.racket-lang.org/xml/index.html#%28def._%28%28lib._xml%2Fmain..rkt%29._source%29%29> say something about symbols.) Regardless, rather than using an ad-hoc encoding scheme for the entities Apple has odd rules about, you can just replace them with symbols or `valid-char?`s and let the library take care of everything. Well, my example code for that has grown complete enough that I'll just make a PR shortly :) -Philip -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/0100017cbc714ad9-99e03c7f-69ae-43c1-92d4-58536cab5278-000000%40email.amazonses.com.
