Skip to content

Roadmap

Brian Stafford edited this page Sep 1, 2021 · 1 revision

Roadmap

While libESMTP has had a stable API for more than a decade it is not without a few deficiencies that could make some programming tasks more difficult than they need to be. Future development will address these issues while maintaining backward compatibility with contemporary releases.

Accessors

As originally written it was anticipated that each of libESMTP's opaque structures would simply be populated and forgotten about. Unfortunately this design decision has had (at least) two consequences: 1) the event callback arguments have evolved arbitrarily as efforts were made to supply information to the application, and 2) applications are obliged to provide their own code to shadow some or all of the values set in libESMTP's structures. Both issues have proven problematic when writing a language binding.

Accessors are planned for the libESMTP 1.2.0 release.

Iterators

The libESMTP API provides for iteration of messages or recipients, for example, by provinding an API which takes a callback function. This works quite well for C programs but has proven difficult to manage when writing a language binding. Often code using iterators is clearer and more concise than equivalent code using a callback.

Iterators are planned for the libESMTP 1.2.0 release.

Callbacks

Message Callback

The callback API for reading messages is, on reflection, poorly designed since it is a single function serving at least two distinct purposes; these are distinguished by overloading the callback arguments in unexpected (and previously undocumented) ways.

A better approach is to follow a more traditional open - read - close paradigm implemented as distinct functions. Such a change reaches more deeply into the libESMTP code so it is likely that the existing message API would have to be reimplemented over the new one.

This model should be better suited to providing language binding features such as Python's 'file-like' object or a C++ iostream.

It is hoped to have an improved message callback ready for libESMTP 1.2.0.

Event Callback

The event callback was a later addition to the libESMTP API; as previously noted the callback's variadic argument list has since evolved inconsistently. Because the callback arguments are variadic, any form of type checking is impossible.

As a minimum the callback arguments should be rationalised, for example, arguments that may be queried via the accessors can be removed and the number of variations of the argument list reduced. A more radical redesign might be useful to facilitate a signal-slot mechansim found in many languages such as those provided by libsigc++ or Boost. Ideally an updated mechanism should coexist with the current callback.

It is hoped to have an improved event mechanism ready for libESMTP 1.2.0.

SASL

The SASL mechanisms provided with libESMTP are dated nowadays. A review of current RFCs is in order and a selection of contemporary authentication modules should be added to the current suite. Parallel support for GNU SASL may also be added, some speculative code for this is already available on the gsasl development branch.

New SASL mechanisms may be added without affecting either API or ABI.

Unit Tests

Where possible, unit tests shall be added.

Clone this wiki locally