Re: [MIT-Scheme-devel] a MIME body structure parser for non-IMAP folders in IMAIL

[Chris Hanson]

On 11/28/05, Taylor Campbell <address@hidden> wrote:

> If I wish to include it in MIT Scheme, would it be most convenient to
> assign the copyright to MIT?  I'm uninterested in being swamped in
> legal matters, so I would opt for the simplest path in that regard;

The simplest thing is for you to retain copyright on it.  Then there
are no legalities to deal with, just add a copyright line to the file.

> also, a bit of the code is very similar to existing code in Edwin,
> such as a slightly extended RFC822 header field value tokenizer.

Perhaps it would be better to just extend the existing tokenizer. 
What kind of extensions?

> Is there any way to cache the Boyer-Moore string search table and then
> to reuse it for multiple searches?  Judging by the source of its
> implementation in runtime/string.scm, this is not possible, but it
> would seem to be a very useful operation.

It doesn't seem that it would be hard to make this change.  Do you
want to try?  I'll review it (or advise) if you're not sure.

I assume you're using this for the parser?  Did you consider using the
parser language?  It's well suited to this application, and takes care
of things like backtracking.

> I'm unclear on how line endings are managed in the new I/O system and
> IMAIL's infrastructure.  String input/output ports don't seem to
> translate line endings, regardless of PORT/SET-LINE-ENDING.  Is it
> reliable that IMAIL messages will contain only #\NEWLINE characters,
> not CRLFs, if their contents are taken by passing a string output port
> to WRITE-MESSAGE-BODY?  (The MIME parser currently relies on this.)
> If not, what can I rely on?

Yes, this is reliable.  Internal representations of messages always
use newline for the line separator.