Hi Klaus,
Klaus Darilion wrote:
Daniel-Constantin Mierla wrote:
- generic communication interface which must offer an abstract layer
between core/modules and transports (e.g., fifo, unix sockets)
- move the code of the implemented trasports as module
- NAPTR lookup
with failover to next server/protocol? interpret ICMP error messages
first step will be only NAPTR lookup and interpretation of priorities, protocols, etc.
- TLS multi-domain support
- TLS configuration values to be set via a module, to keep core less
exposed
I will write a separe emails for my TLS ideas :-)
ok :)
- security checks of destination addess (white/black lists)
maybe not only based on IP address, but IP address, port and protocol (which may be also * for all ports/protocols)
yes, makes sense
[enum] [-] - parallel/serial forking based on order and preference fields
isn't this already possible using load_gw, next_gw?
the idea behind was to move the functionality of load_gw and next_gw into core to allow a standard mechanism for serial forking for all modules (without interdependencies). Enum, registrar, NAPTR lookup, etc will be able to do serial forking also without depending of lcr module.
[postgres]
- connection pool
- shift to memory manager used by openser
there was a big patch by jan for ser - maybe we can use this patch.
can you extract the patch ;)?
regards, bogdan