Re: [WIP-PATCH 1/2] send-email: create email parser subroutine
- From
- Eric Wong <e@80x24.org>
- Date
- Jun 2, 2016, 19:58 UTC
- Message-ID
- <20160602195855.GA17627@dcvr.yhbt.net>
- In-Reply-To
- <9535d962-5479-5a13-472e-cd558ef163e0@grenoble-inp.org>
Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
Show 36 quoted lines
> On 05/29/2016 01:33 AM, Eric Wong wrote: > >Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > >>Samuel GROOT <samuel.groot@grenoble-inp.org> writes: > >> > >>>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).
Show 7 quoted lines
> 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.