Let messages and grouped AVPs be encoded/decoded from/to maps

With {record_decode, map}. The option name is arguably a bit misleading
now, but not too objectionable given that the encode/decode in question
has historically only been of records.

One advantage of the map decode is that the map only contains values for
those AVPs existing in the message or grouped AVP in question. The name
of the message or grouped AVP is stored in with key ':name', the leading
colon ensuring that the key isn't a diameter-name.

Decoding to maps makes the hrl files generated from dictionary files
largely irrelevant. There are value defines generated into these, but
they're typically so long as to be unusable.

1 files changed, 7 insertions, 2 deletions

diff --git a/lib/diameter/doc/src/diameter_codec.xml b/lib/diameter/doc/src/diameter_codec.xml
index 0117c1c88a..6262dbf00d 100644
--- a/lib/diameter/doc/src/diameter_codec.xml
+++ b/lib/diameter/doc/src/diameter_codec.xml
@@ -230,7 +230,7 @@ header.</p>
 </item>
 
 <tag>
-<marker id="message"/><c>message() = record() | list()</c></tag>
+<marker id="message"/><c>message() = record() | list() | map()</c></tag>
 <item>
 <p>
 The representation of a Diameter message as passed to
@@ -240,7 +240,12 @@ a message as defined in a dictionary file is encoded as a record with
 one field for each component AVP.
 Equivalently, a message can also be encoded as a list whose head is
 the atom-valued message name (as specified in the relevant dictionary
-file) and whose tail is a list of <c>{AvpName, AvpValue}</c> pairs.</p>
+file) and whose tail is a list of <c>{AvpName, AvpValues}</c> pairs,
+or as a map with values keyed on AVP names and the message name in key
+<c>:name</c>.
+The format at decode is determined by &mod_service_opt;
+<c>record_decode</c>.
+Any of the formats is accepted at encode.</p>
 
 <p>
 Another list-valued representation allows a message to be specified