Comparison of Dryverl and EDTK 1.1

Dryverl is the continuation and a rewrite of Scott Lystig Fritchie's Erlang Driver Toolkit 1.1. Dryverl reuses the main ideas of EDTK 1.1, but they differ in many ways because they have different objectives: Dryverl's objectives are maximum flexibility and efficiency, whereas EDTK's objective is to make it easy to specify bindings for the common cases.

Advantages

The advantages of Dryverl over EDTK 1.1 are:

Dryverl is implemented in XSLT 1.0, the widespread W3C standard for specifying transformations of XML documents for which many compilers exist, instead of the iMatix GSLgen library used by EDTK, and which has not been maintained since 2000; this makes Dryverl much easier to maintain and use than EDTK;
bindings generated by Dryverl use only documented functions, whereas EDTK-generated bindings use private / undocumented C functions such as sys_alloc;
Dryverl better integrates into the Open Telecom Platform, by implementing port owning processes using the gen_server behaviour, and by making clients perform calls (for “two-way” bindings) and casts (for “one-way” bindings) to it;
the Dryverl binding specification language is extensively documented in a complete XML Schema, allowing to validate referential integrity constraints, etc., whereas EDTK has no documentation at all;
Dryverl allows to specify a different name for an Erlang function and for a C function that implements it, and even it allows to write the C part of an Erlang binding directly in the binding specification, without requiring to implement it as separate C functions -- EDTK only allows to wrap existing C functions in Erlang functions with the same name;
Dryverl allows to (un)marshall any kind of Erlang terms as arguments and return values, by systematically using internally the standard erl_interface library, instead of the limited port driver APIs which EDTK is limited to, and which cannot (un)marshall references, pids, etc.;
Dryverl bindings transparently and automatically use port_call/2 instead of port_command/2 whenever possible, i.e. when no binaries must be passed by reference, since port_call/2 is a faster alternative, while EDTK always uses port_command/2;
Dryverl clearly distinguishes all the steps in an Erlang-to-C call, and allows to precisely customize every step: input marshalling, input unmarshalling, C body execution, output marshalling, output unmarshalling; the EDTK language is more declarative, and focuses only on function signatures and meta-data associated with signature elements (arguments, return values, etc.), and does not permit to precisely customize calls;
communication between Erlang and a Dryver-generated driver should be more efficient than using EDTK, in terms of the number of bytes sent, since one can precisely specify what data is communicated, whereas EDTK always marshalls all Erlang arguments as-is, even if some are not used in the driver implementation;
Dryverl allows to specify bindings with no output marshalling and output unmarshalling steps, to implement “one-way” bindings where calls are executed in parallel with the caller and don't return values; EDTK allows to specify“two-way” calls only;
manipulation of value maps (i.e. maps between C values and integer identifiers communicated with Erlang programs) is more flexible: entries can be searched, added and removed at any step in a call; in EDTK, entries can be added or removed only when a function returns, and searched only before a function call;
in Dryverl, value maps can allocate new entries dynamically when the pre-allocated entries are all used, while EDTK simply crashes in such cases (stops the driver with a ENOMEM error);
in Dryverl, value maps can be configured, in binding specifications, to transparently use hash maps, for searching either identifiers or C values or both, to improve access speed at the expense of a higher memory consumption for the additional hash tables;
in Dryverl, value map entries identifiers are “more unique”: they are generated using an unsigned long counter and are checked for duplicates; in EDTK, identifers are indexes of the table of pre-allocated entries, which makes it very probable to reuse the identifier of a recently-removed entry, hence makes bugs more probable when identifiers are wrongly used by an Erlang program after the entry has been removed;
Dryverl allows to specify the edoc documentation / specification of the generated Erlang functions.

Drawbacks

The advantages of EDTK 1.1 over Dryverl are:

the Dryverl binding specification language is much more verbose than the EDTK language for specifying simple bindings; however, the EDTK language is much more limited, and is less usable than Dryverl, or even unusable, for specifying complex bindings;
EDTK allows to transparently execute a generated port driver as a port program, which is much safer but less efficient, whereas Dryverl currently can only generate port driver implementations; however, it is possible to generate implementations of port programs and C nodes from Dryverl binding specification as well, although this is not yet implemented.

Integrating Dryverl And EDTK

Since Dryverl and EDTK have different objectives, and have different advantages, it makes sense to keep both specifications languages, i.e. the EDTK language for specifying simple bindings, and the Dryverl language for specifying other bindings. However, maintaining two implementations would be a duplication of efforts. Since Dryverl is more flexible and efficient, it a better implementation base. Therefore, it would be useful to rewrite EDTK to generate Dryverl specification from the simpler EDTK specifications, instead of generating C and Erlang code directly (and not the other way around, i.e. making Dryverl generate EDTK specifications).

This way of integrating Dryverl and EDTK is consistent with the view of Dryverl as an Erlang-to-C binding “assembly language”, as described in the project's workplan.