Re: [PATCH v4] send-email: Add simple email aliases format
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- May 22, 2015, 18:49 UTC
- Message-ID
- <CAPig+cRc=u=AKRgp3Dn5De13WcMYFXr1QomzPY0rXAwpN5WwLA@mail.gmail.com>
- In-Reply-To
- <CAJ80savzM_BL2oPiyTaPYAgnNL7F571aumGJLLw76vtryTacrg@mail.gmail.com>
On Fri, May 22, 2015 at 2:01 PM, Allen Hubbe <allenbh@gmail.com> wrote:
Show 18 quoted lines
> On Fri, May 22, 2015 at 12:53 PM, Eric Sunshine <sunshine@sunshineco.com> wrote: >> On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe <allenbh@gmail.com> wrote: >>>> For the same reason, I'm not convinced that "simple" is a good name. >>>> "sendmail" may indeed be a more appropriate name, even if it means >>>> that this early implementation documents it as (currently) a subset of >>>> the richer sendmail/postfix 'aliases' format. By doing so, we leave >>>> the door open so a future person can implement additional features to >>>> bring it closer to that format. >>> >>> Or, a future person can write a sendmail parser that is closer to that format. >> >> Yes, but git maintainers must continue to support your "simple" format >> even if someone comes along later and adds a more proper sendmail-like >> format alongside. > > Someone might implement a sendmail parser in the future, or perhaps > never. So, there is the possibility. How strong of a reason is that > to reject some other format that is based on a colon?
Nobody has suggested that your format should be rejected. Rather, the issue raised regards gratuitous divergence from the sendmail 'aliases' format. You seem to be arguing in favor of gratuitous divergence (without explanation) despite the proposed "proper subset" approach serving your use-case just as well.
Show 9 quoted lines
> What is the harm of the two side by side? This is only a small bit of > code that really shouldn't require much maintenance. What is the harm > to just leave it in? > > If the future sendmail parser happens to support the simple format, > and the future maintainers determine the situation to be unacceptable, > there is still a solution. Simply define both names 'simple' and > 'sendmail' to refer to the same sendmail parser. The dead code can be > removed.
This "simple solution" doesn't work if your new format diverges from the sendmail 'aliases' format, which is why the issue is being raised now, in order to avoid painting ourselves into that corner. If, on the other hand, your new format remains a proper subset of sendmail 'aliases', then the "simple solution" does work; and, as a proper subset, it can just as well be named "sendmail" without hurting any future effort to implement missing functionality.