From 1b3b64af3d9a5441b6da37cf4e97b59cb043f33b Mon Sep 17 00:00:00 2001
From: Anders Svensson <anders@erlang.org>
Date: Thu, 6 Jul 2017 11:02:31 +0200
Subject: 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.
---
 lib/diameter/doc/src/diameter.xml       | 9 +++++----
 lib/diameter/doc/src/diameter_codec.xml | 9 +++++++--
 2 files changed, 12 insertions(+), 6 deletions(-)

(limited to 'lib/diameter/doc/src')

diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml
index 663c9cc785..bfb6da41b5 100644
--- a/lib/diameter/doc/src/diameter.xml
+++ b/lib/diameter/doc/src/diameter.xml
@@ -539,7 +539,7 @@ that matches no peer.</p>
 <p>
 The <c>host</c> and <c>realm</c> filters cause the Destination-Host
 and Destination-Realm AVPs to be extracted from the
-outgoing request, assuming it to be a record- or list-valued
+outgoing request, assuming it to be a record-, list- or map-valued
 <c>&codec_message;</c>, and assuming at most one of each AVP.
 If this is not the case then the <c>{host|realm, &dict_DiameterIdentity;}</c>
 filters must be used to achieve the desired result.
@@ -970,13 +970,14 @@ occur in the message in question.</p>
 </item>
 
 <tag>
-<marker id="record_decode"/><c>{record_decode, boolean()}</c></tag>
+<marker id="record_decode"/><c>{record_decode, boolean() | map}</c></tag>
 <item>
 <p>
 Whether or not to decode message and grouped AVPs to records in the
 <c>msg</c> field of diameter_packet records and <c>value</c> field of
-diameter_avp records respectively.
-If <c>false</c> then the fields are set to the same value.</p>
+diameter_avp records respectively, or to an alternate format.
+If false then the fields are set to the same value.
+See also &codec_message;.</p>
 
 <p>
 Defaults to <c>true</c>.</p>
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
-- 
cgit v1.2.3