deliver is the binary name. but it's configured inside protocol lda {}
section. This is getting annoying, any thoughts on what would be a good
unifying name?
a) deliver binary, protocol deliver {}
b) lda binary, protocol lda {}
c) dovecot-lda binary, protocol lda {}
d) mda binary, protocol mda {}
e) dovecot-mda binary, protocol mda {}
f) something else?
In any case protocol lda {} would work for a while longer for backwards
compatibility.
c) and e) choices also makes me think if e.g. imap and imap-login should
be called dovecot-imap and dovecot-imap-login instead. People have had
trouble finding them since ps|grep dovecot doesn't find them..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090407/183e8917/attachment-0002.bin>
Timo Sirainen wrote:> deliver is the binary name. > > a) deliver binary, protocol deliver {}The problem I have with the deliver name in general is that there is a pre-existing LDA project[1] with the same name, and even within the scope of the Dovecot mailing list, it isn't a unique term, so it makes it harder to sift out information specific to the LDA sub-project. 1. http://packages.debian.org/etch/deliver> c) dovecot-lda binary, protocol lda {}This gets my vote. (Assuming "Dovecot-lda" replaces the "deliver" name in the documentation, as well.)> c) and e) choices also makes me think if e.g. imap and imap-login should > be called dovecot-imap and dovecot-imap-login instead. People have had > trouble finding them since ps|grep dovecot doesn't find them..Agreed. -Tom
On Wed, 2009-04-08 at 04:01, Timo Sirainen wrote:> deliver is the binary name. but it's configured inside protocol lda {} > section. This is getting annoying, any thoughts on what would be a good > unifying name? >annoying? who complains? I suspect a negligible number of people.> a) deliver binary, protocol deliver {} >changing protocol would be a huge mistake due to its current widespread use and I can envisage many many many complaints of "it stopped working" etc, lets face it, most people don't read changelogs in detail, if at all, and almost all are used in automated startups so start-up warnings are not really much use.> > c) dovecot-lda binary, protocol lda {}if you absolutely must change the binary name, then C would be my option, but be warned of the above caution for this as well. Basically, if it aint broke, why break it?
Timo Sirainen wrote:> deliver is the binary name. but it's configured inside protocol lda {} > section. This is getting annoying, any thoughts on what would be a good > unifying name? > > c) dovecot-lda binary, protocol lda {}I'd vote for C as well.
Timo Sirainen wrote:> deliver is the binary name. but it's configured inside protocol lda {} > section. This is getting annoying, any thoughts on what would be a good > unifying name? > > a) deliver binary, protocol deliver {} > > b) lda binary, protocol lda {} > > c) dovecot-lda binary, protocol lda {} > > d) mda binary, protocol mda {} > > e) dovecot-mda binary, protocol mda {} > > f) something else? > > In any case protocol lda {} would work for a while longer for backwards > compatibility. > > c) and e) choices also makes me think if e.g. imap and imap-login should > be called dovecot-imap and dovecot-imap-login instead. People have had > trouble finding them since ps|grep dovecot doesn't find them.. >Having a consistent name prefix for all the processes sounds nice - but then you'd stick out as the exception to typical multi-process server names (like Postfix's master, smtpd, cleanup, etc.). Is it a Good Thing to deviate from accepted (poor) practices? Hmm.... Other tradeoffs...more space consumed in logfiles. More screen width consumed during listings. Not necessarily a Good Thing - not necessarily a Bad Thing. But something to ponder on. I would also consider the Dovecot architecture. As I (mis)understand it, the "dovecot" process spawns the necessary imap, pop3, and login daemons. So having a "dovecot.conf" file for controlling these is quite appropriate. However, unless I've missed something (quite likely) - "deliver" has nothing to do with the listening daemons. So having the "lda" configuration in the dovecot.conf file might be inappropriate - I would suggest splitting that off to a "dovecot-lda.conf" file (or whatever you change the delivery agent name to). I like option c. -- Daniel
Timo Sirainen wrote:> deliver is the binary name. but it's configured inside protocol lda {} > section. This is getting annoying, any thoughts on what would be a good > unifying name? > > c) dovecot-lda binary, protocol lda {}I'm in favor of this ... outside of dovecot, explicitly saying dovecot is important, whereas inside the config file, it's implicit we're talking about Dovecot's LDA. dovecot-lda also fits with the dovecot-auth precedent. Of course, saying "dovecot-imap-login" is getting a bit too verbose :P -- Curtis Maloney cmaloney at cardgate.net
Timo Sirainen wrote:> deliver is the binary name. but it's configured inside protocol lda {} > section. This is getting annoying, any thoughts on what would be a good > unifying name?I hope you didn't intend such a bikeshed discussion :)> c) dovecot-lda binary, protocol lda {}This is perfectly fine.> c) and e) choices also makes me think if e.g. imap and imap-login should > be called dovecot-imap and dovecot-imap-login instead. People have had > trouble finding them since ps|grep dovecot doesn't find them..Good idea.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 7 Apr 2009, Timo Sirainen wrote:> c) dovecot-lda binary, protocol lda {}> e) dovecot-mda binary, protocol mda {} > > c) and e) choices also makes me think if e.g. imap and imap-login should > be called dovecot-imap and dovecot-imap-login instead. People have had > trouble finding them since ps|grep dovecot doesn't find them..Yeah: "deliver" is too generic, I think. I'd prefer c) over e), but just a bit. Currently, I symlink the Dovecot "deliver" to "dovecot-deliver", to know what deliver it is. Bye, - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSd20wnWSIuGy1ktrAQKtmQf/bbNsl8aEJAI1EFpDHnAnKoDMPaLrOyRE 56yF93GMzlZWZPrNqbDalC//4kWpyNGVlJ5Ly546vdToXWFxO2YMx+uVzbMx0GOg RmWkOMajPkiqaPmUlYimbvMcbQBct1I3OsLHxcAua1ks4Tv7TT1K3Ftkj/nWo9y3 5+Y5RJH4SD/SEsWd02ydgJuMkuVGrrpjGfyjOkNfg1RUh+Dh9eUUsgLMYfnGftop cdzoxO7x7UMJdJgPgLskDaBA7wrGWYvVK2uRYcBERr9P9LGRkp5w6iWPyleMxbtH akj5z9CUCC5WeUa5ffNOJRhDjOT6rHl4b+ecu4/RLuQmTpKQm0ofMA==k2jf -----END PGP SIGNATURE-----
On Tue, 2009-04-07 at 14:01 -0400, Timo Sirainen wrote:> deliver is the binary name. but it's configured inside protocol lda {} > section. This is getting annoying, any thoughts on what would be a good > unifying name?Hmm. I just realized. Once I implement LMTP server, it needs to read the same settings as deliver. And perhaps it also needs some of its own settings?.. So I'm thinking that the whole protocol lda {} section should go away in dovecot-example.conf. Only if you truly want some settings to be read only by deliver you should add it and put stuff in there. LMTP server would also read only protocol lmtp {} section. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20090411/f1793bc6/attachment-0002.bin>
On Sun, 2009-04-12 at 13:45, Timo Sirainen wrote:> > Hmm. I just realized. Once I implement LMTP server, it needs to read the > same settings as deliver. And perhaps it also needs some of its own > settings?.. So I'm thinking that the whole protocol lda {} section > should go away in dovecot-example.conf.I hope you mean just commented out, as I'd think that many would use at least mail_plugins, quota_full_tempfail, and log_path