Re: [WIP-PATCH 1/2] send-email: create email parser subroutine

Samuel GROOT [off-list ref] wrote:

On 05/29/2016 01:33 AM, Eric Wong wrote:

quoted

Matthieu Moy [off-list ref] wrote:

quoted

Samuel GROOT [off-list ref] writes:

quoted

Parsing and processing in send-email is done in the same loop.

To make the code more maintainable, we create two subroutines:
- `parse_email` to separate header and body
- `parse_header` to retrieve data from header

These routines are not specific to git send-email, nor to Git.

Does it make sense to use an external library, like
http://search.cpan.org/~rjbs/Email-Simple-2.210/lib/Email/Simple.pm ,
either by depending on it, or by copying it in Git's source tree ?

That might be overkill and increase installation/maintenance
burden.  Bundling it would probably be problematic to distros,
too.

We have 5 solutions here:

  1. Make a new dependence to Email::Simple.

  2. Bundle Email::Simple in Git's source tree.

  3. Use Email::Simple if installed, else use our library.

  4. Making our own email parser library.

  5. Duplicate parser loop as we did for our patch to implement
     `--quote-email` as proposed in $gmane/295772 .

Obviously, option (5) is the easiest one for us, but it leaves refactoring
for later, and option (1) is also easier but adds a new dependence which is
not that good.

I would go with (5) for now and leave (4) for later (which
might just be moving the function to a new file).

Since our project ends next week, we might not have enough time to finish
developing a custom parser API so (4) is not a viable option for now but
could be done in the future.

We could consider bundling Email::Simple as the best option, as it's
developed since 2003 and might be safer to use than anything we could write
in several weeks.

In an ideal world, (1) would be nice.  But (IMHO) git-send-email
should remain installable on non-ideal systems which do not
provide Email::Simple as a package.

(2) would probably be non-ideal for distro maintainers
(+Cc: Jonathan for opinions), and (3) is the most complex
and difficult-to-support.