From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] [PATCH] Add new :crypto_default configuration option.
Date: Thu, 01 Oct 2009 10:31:00 -0700 [thread overview]
Message-ID: <1254417826-sup-6584@yoom.home.cworth.org> (raw)
In-Reply-To: <1254416783-sup-5518@masanjin.net>
Excerpts from William Morgan's message of Thu Oct 01 10:07:20 -0700 2009:
> I like the idea, but how about a hook instead? I think the reply-mode
> hook is exactly equivalent to this. (Which maybe I will one day rename
> to default-reply-mode.)
>
> I have a strong aversion to adding configuration options.
I'm intrigued.
What makes a hook preferable over a configuration option?
I've been getting concerned watching the number of hooks in sup grow
as each creates a maintenance burden. Either:
1. All hooks are supported forever with consistent
arguments/semantics, (which may make it more difficult to make
changes in sup than it would be otherwise)
OR:
2. Hooks are not supported forever, in which case users may find that
things just start working when upgrading.
Neither of those seem options look nice to me, and both seem easy to
avoid with configuration options.
If the plan is to go with (1) I'm concerned that I don't see sup
shipping documentation for the current possible hooks. (This applies
to configuration options too though. I think the maintainer should
reject patches that add either without also adding documentation to
the standard list.[*])
[*] Assuming the pre-condition of such documentation existing of
course.
On the other hand, I also dislike configuration options (and hooks,
equally), to the extent that they might be used as an excuse to avoid
putting the most sane and useful default functionality into sup
itself. Obviously, this can be complicated by some people not agreeing
on what the most sane and useful behavior is.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/55fc7ab2/attachment.bin>
next prev parent reply other threads:[~2009-10-01 17:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-28 22:57 Carl Worth
2009-10-01 17:07 ` William Morgan
2009-10-01 17:31 ` Carl Worth [this message]
2009-10-06 17:16 ` William Morgan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1254417826-sup-6584@yoom.home.cworth.org \
--to=cworth@cworth.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox