Wietse Venema wrote in
<4bcnlx0tr4zj...@spike.porcupine.org>:
|Steffen Nurpmeso:
|> Wietse Venema wrote in
|> <4bcgr00pr0zj...@spike.porcupine.org>:
|>|Steffen Nurpmeso:
|>|> It would be great if a hook could be called for such events. Even
|>|> a simple fork+detach+exec+forget approach would be really great,
|>|> with an event indicator and an IP address as an argument.
|>|
|>|We don't do ad-hoc special-case solutions.
|>
|> Yes. That is good. But, on the other hand, trying to create
|> a very generic interface can become an endless undertaking.
|
|No, it doesn't. But, as this thread has already demonstrated, doing
Yes, i tend to disagree. Say you want to have a generic object
tree based MIME parser / representation, doing this really right
requires a lot of infrastructure, like string objects, collection
objects, configurable / hookable memory allocation routines, even
the basic plain old data types (even though today one could use
stdint). Of course an approach to I/O. You possibly want to have
generic iteration support that is able for the MIME tree as well
as for all the collection objects. You possibly want
a generically usable event/sender mechanism. All the objects need
a properly designed interface to make themselves generically
usable, you need documentation, and, of course, unit tests. You
end up needing an entire infrastructure, and you surely want to
extend usage of this infrastructure the entire application. That
is a major undertaking.
On the other hand, once you have it, you can walk pretty joyfully
from there on, more or less. I think dovecot just created another
I/O stream encapsulation layer (i have forgotten the details from
their announcement), and this seems to have been pretty
straightforward (i track the sources for some years, check in the
releases ball-by-ball into git(1), and can then see the diff
easily, and did, out of interest).
|a proper job does take more thought than a quick fix. Fred Brooks
|estimated the cost difference between an ad-hoc program versus
|code that is part of at maintainable system.
In Germany we say "Zu viele Köche verderben den Brei", "too many
cooks ruin|adulterate|.. the pulp". (I have not read the book.)
|In this case, it would require a logging API that takes a 'server
|state' argument, plus a callback function that serializes that server
|state as name-value pairs along with the error messge. It should
|probable be JSON format, but other loss-free formats would work, too.
I think this is unfair. In the meantime i have seen a few lines
of postfix code in smtpd and xsasl (and a bit milter), and i have
seen a lot of code duplication where msg*() and smtp_chat_reply()
come in pairs (but not always), at least. I have seen
C preprocessor statements which define strings, and then
assignment of these CPP macros to some state variable, but the
same string fully spelled out as a part of some logging / reply
(??), thus with the potential of running out of sync. A lot of
in-string definitions of SMTP codes, where possibly generic CCP
macros could also be used (and would be searchable more easily).
Just to mention it.
A new feature would be new and could be clean, _of_course_.
A generic [logging] API could also replace all things which
currently exist, say, replace
msg_warn("Refusing STARTTLS request from %s for service %s",
state->namaddr, state->service);
smtpd_chat_reply(state,
"454 4.7.0 Error: too many new TLS sessions from %s",
state->namaddr);
with a hypothetic
smtp_emit(state, 454 | ERROR | CHAT | WARN | WARN_APPEND_SERVICE,
"4.7.0 too many TLS .. %s",
"Refusing STARTTLS request from %s",
state->namaddr);
which could then be dispatched to several things, including
msg_warn, smtp_chat_reply as well as a generic notification
mechanism (however changing the message to "Refusing STARTTLS
request from %s (service XX)").
I do not know whether this is really possible.
And serializing the entire state is tough. JSON, puh. :-)
I like traditional binary, like A\0B\0\0. Or CBOR, a nice (JSON)
binary format. However, i see, postfix already does some JSON, in
postqueue.
Have you ever heard of libxo? FreeBSD makes use of it and changed
many of its traditional UNIX applications, the output format can
now be controlled via command line, they can output text, xml or
json (maybe even cbor now). I never used the possibilities (my
scripts must run on several systems).
This library uses format strings almost identical to the well
known C etc format strings, converting an entire application from
on to the other should not be too problematic, is possibly even
doable with automatic help.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
