Restarting from this proposal to make a summary:

2017-12-04 14:16 GMT+01:00 Stefan Eissing <stefan.eiss...@greenbytes.de>:

> Not much input regarding this naming change. Personally, I like to keep
> '<ManagedDomain' as is.
>
> I propose the following changes:
>
> 1. The simple, single line 'ManagedDomain' will be renamed to 'MDGroup'
> 2. The not so intuitive differences between 'MDMember' and 'MDMembers'
> will be solved by removing the 'MDMembers' directive. 'Auto' membership is
> now always the default mode and can no longer be changed globally. 'Manual'
> membership mode must be set explicitly for every MDGroup/ManagedDomain that
> shall behave like that.
> 3. 'MDStoreDir' will be renamed to 'MDStore' to leave room for future,
> non-file based storage methods.
> 4. 'MDCAChallenges' will be renamed to 'MDCertificateChallenge' to have
> the same prefix as other directives for the signup/renewal protocol
> 5. 'MDPrivateKeys' will be renamed to 'MDPrivateKey' as it was the last
> one that used a plural wording.
>
> If no one objects, I will do the changes in the upcoming days.
>

So two things seem outstanding, if I got it correctly, reading from
multiple threads:

1) ManagedDomain vs <ManagedDomain>: the similarity between the two
directives may confuse users in the long term, so we should find a better
naming.
2) The mod_md name may not be evocative enough for what it does (also no
mention of TLS/SSL in its directive names, use a terminology like "domain"
that is too broad, etc..).

My personal view:

I like Stefan's idea to renamed ManagedDomain as MDGroup (so all the
directives of mod_md will have the MD prefix) but the remaining
<ManagedDomain> (that IIUC is not changed) should also be renamed to say
something like MDGroupDefine/MDGroupSandbox/MDGroupWhatever. We used the
"Define" suffix for the SSLPolicy vs <SSLPolicyDefine> use case, so it
might be a possibility to follow the same path with MDGroup /
<MDGroupDefine>.

At this point I would concentrate on gathering consensus on a solution for
point 1), and use our docs to solve point 2). I do believe that it is a bit
too late to start a rename for mod_md due to early adopters and
announcements made, plus the (generic) name might allow us to add
non-ACME-related features in the future.

My main concern is that months of work spent into this awesome module get
stuck for a long time due to naming debates (that are important but need to
come to a conclusion soon :).

Luca

Reply via email to