| Age | Commit message (Collapse) | Author |
|---|
|
introduced after OTP_R13B03.
|
|
|
|
diameter_codec(3) referred only to the record format in places. The
configurable format was added in commits 722fa415 and then 55e65b26.
|
|
Use the same [MsgName | Avps] representation as for the list decode, but
with Avps a map instead of a AVP name/values list. As a result, don't
set the message/AVP name on an additional key in the map, which felt a
bit odd. Messages are [MsgName :: atom() | map()], Grouped AVPs are just
map().
Fix at least one problem in the traffic suite along the way: with
decode_format false, the own decode in to_map/2 didn't know whether or
not to decode strings, resulting on some failures.
|
|
{record_decode, map} is a bit too quirky.
|
|
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.
|
|
The documentation has been out of date since the string_decode option
was added in commit 1590920c. The optionless decode/2 was removed in the
commit that removed the use of the process dictionary in decode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not yet any content to speak of.
|
