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 racket-users+unsubscr...@googlegroups.com. 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.
