tvl-depot/third_party/lisp/mime4cl/README.md
sterni ee9c3c254c docs(3p/lisp/mime4cl): add clear warning about current state
I'm not really describing what the problem here is because I don't
think a writeup is really useful. It would just be speculation and
I don't need to syncronize my efforts with anyone at the moment,
so it's best to keep those notes offline.

Basically, the next problem I want to tackle is that the initial
parsing of a multipart message (to get the number, types, offsets
etc. of the different parts) is very slow. This is because READ-LINE
on a FLEXI-STREAM dispatches to READ-CHAR which is laughably slow.

Change-Id: Ia5d6e335abb23639cfe9c2149ead99ffa5dbbcf5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12936
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
2024-12-31 22:20:19 +00:00

1.3 KiB

mime4cl

MIME4CL is a Common Lisp library for dealing with MIME messages. It was originally been written by Walter C. Pelissero and vendored into depot (mime4cl-20150207T211851.tbz to be exact) as upstream has become inactive. Its original website can still be accessed.

The depot version has since diverged from upstream. Main aims were to improve performance and reduce code size by relying on third party libraries like flexi-streams. It is planned to improve encoding handling in the long term. Work towards this happens intermittently.

WARNING: mime4cl currently doesn't have a comprehensive test suite and decidedly lacks performance.

Differences from the original version

  • //nix/buildLisp is used as the build system. ASDF is currently untested and may be broken.

  • The dependency on sclf has been eliminated by inlining the relevant parts.

  • MY-STRING-INPUT-STREAM, DELIMITED-INPUT-STREAM, CHARACTER-INPUT-ADAPTER-STREAM, BINARY-INPUT-ADAPTER-STREAM etc. have been replaced by (thin wrappers around) flexi-streams. In addition to improved handling of encodings, this allows using READ-SEQUENCE via the gray stream interface.