A discussion about how to better handle mail content got me thinking. The situation is that "a mail" is actually a tree where there are one or more "root" mail bodies (one for text, one for HTML, and maybe one with rich text). Then there are some attachments and these attachments are (or are not) referenced from the roots. The attachments can be forwarded mails, inline images or attached files.

Detecting and handling such attachments is inconvenient as I always feel that I'm doing manual tree iteration using MIME::Parser and MIME::Entity. As manually doing this is inconvenient and also hides the logic that I actually want. Having a different way to specify the things I'm interested in would make my code clearer.

I wonder what makes more sense, an SQL/DBI interface, so I can say something like

select parent_obj
     , entity_obj
  from parsed_mail
 where mime_type='image/jpeg'
   and content_disposition='attachment'

Alternatively, an XPath-style query like

 //mail/item[@mime_type="image/jpeg"
   and @content-disposition="attachment"]

but XPath gets unwieldly due to the quoting, while SQL is more verbose. I don't like inventing my own language since I usually fail at that and using a known query language gives me existing tools that I can leverage.

I guess I'll have to implement or at least mock up both query styles, and maybe also CSS as a query style, to see how the different queries would/could be formulated. Example queries would be

• give me all attachments of this (nested/forwarded) mail
• give me all inlined images of this mail
• give me the mail text of this mail, preferring HTML over RTF over plain text

Last Saturday, I played through Senua's Sacrifice, a game first released 2017 to critical acclaim.

The game was rather disappointing - the story is good, but the gameplay is a mix between a walking simulator, cutscenes telling a story, some small puzzles and boring melee fights against the same set of five enemies.

Luckily, the game was also quite short, because I don't think I would have spent a second evening with that game.

If you want to play, I recommend getting it on discount and playing it on easiest difficulty. The story is OKish and might entertain you for an afternoon or evening.

JSON Canvas looks interesting. It is far from the interactive infinite canvas display that I like and try to get towards with SVG::Drawboard but having an interactive (enough) renderer for simple input data would be nice, especially if I don't have to program it myself.

I missed last year but in 2024 I'm doing a dev release of Perl again. This time it is version 5.39.7. And again, you can watch it live on Saturday 20th of January on Twitch:

You can expect to watch me talk through the steps of the Perl Release Managers Guide and if you join the Twitch chat, or #p5p on irc.perl.org, we can chat a bit.

I assume I'll start Saturday at 08:00 UTC (10:00 CET), and the whole thing will take around 4 hours unless there are some major mishaps.

Usually I build and test Perl by copying the C compiler from Strawberry Perl. But just today I found w64devkit, which is a distribution of busybox, gcc and mingw-w64, and it works well to compile and test a fresh Perl:

cd perl5/win32
make -j CCHOME=C:\\Users\\Corion\\...\\w64devkit
make -j test