API and build change and fix summaries. Doc correctsions
and/or changes are not mentioned here; see the commit messages.
+2019 December 9; version 1.13.1
+ Correct documentation and missing rel-notes update for RTD.
+
2019 December 6; version 1.13.0
Add ability to route messages based on the MEID in a message combined
with the message type/subscription-ID.
set( major_version "1" ) # should be automatically populated from git tag later, but until CI process sets a tag we use this
set( minor_version "13" )
-set( patch_level "0" )
+set( patch_level "1" )
set( install_root "${CMAKE_INSTALL_PREFIX}" )
set( install_inc "include/rmr" )
&ex_start
meid_map | start
mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
- mme_ar | control2 | meid100 meid101 meid102 meid103
+ mme_ar | control2 | meid100 meid101 meid102 meid103
meid_map | end | 2
&ex_end
This table indicates that the application (endpoint) &ital(control1) "owns" 6 MEIDs
-and &ital(control2) owns 4.
-When message type 0 is sent, the MEID in the message will be used to select the
-endpoint via this table.
+and &ital(control2) owns 4.
+When message type 0 is sent, the MEID in the message will be used to select the
+endpoint via this table.
&space
The MEID table will update the existing owner relationships, and add new ones; it
is necessary to send only the changes with the add/replace (mme_ar) entries in
-the table.
+the table.
When necessary, MEIDs can be deleted by adding an &cw(mme_del) record to the table.
The following example illustrates how this might look:
&ex_start
meid_map | start
mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
- mme_ar | control2 | meid100 meid101 meid102 meid103
+ mme_ar | control2 | meid100 meid101 meid102 meid103
mme_del| meid200 meid401
-meid_map | end | 1
+meid_map | end | 3
&ex_end
&h3(Route Table Syntax)
&ex_end
&space
A round robin group is one or more endpoints from which one will be selected to receive
-the message.
+the message.
When multiple endpoints are given in a group, they must be separated with a comma.
An endpoint is the IP address and port (e.g. 192.158.4.30:8219) or DNS name and port of the
application that should receive the message type.
-If multiple round-robin groups are given, they must be separated by a semicolon, and
+If multiple round-robin groups are given, they must be separated by a semicolon, and
&h3(MEID Map Syntax)
-The MEID map is similar to the route table.
-Entries are used to add or replace the ownership of one or more MEIDs (mme_ar) or to
+The MEID map is similar to the route table.
+Entries are used to add or replace the ownership of one or more MEIDs (mme_ar) or to
delete one or more MEIDs (mme_del).
The following is the syntax for the MEID map.
meid_map | start
mme_ar | <owner-endpoint> | <meid> [<meid>...]
mme_del | <meid> [<meid>...]
-meid_map | end | <count>
+meid_map | end | <count> [| <md5sum>
&ex_end
&space
observed relationship is used.
Each of the lists of MEIDs are blank separated.
+&space
+The optional <md5sum> on the &ital(end) record should be the computed MD5 hash for all
+records which appear between the start and and records.
+This allows for a tighter verification that all data was received exactly as the
+route manager transmitted them.
+
&h3(Environment)
To enable configuration of the library behaviour outside of direct user application
&h2(DESCRIPTION)
The &cw(rmr_bytes2meid) function will copy up to &ital(len) butes from &ital(src) to the
-managed equipment ID (meid) field in the message.
+managed entity ID (meid) field in the message.
The field is a fixed length, gated by the constant &cw(RMR_MAX_MEID) and if len is larger
than this value, only RMR_MAX_MEID bytes will actually be copied.
&uindent
&h2(DESCRIPTION)
-The &cw(rmr_get_meid) function will copy the managed equipment ID (meid) field from the message
+The &cw(rmr_get_meid) function will copy the managed entity ID (meid) field from the message
into the &ital(dest) buffer provided by the user.
The buffer referenced by &ital(dest) is assumed to be at least &cw(RMR_MAX_MEID) bytes in length.
If &ital(dest) is NULL, then a buffer is allocated (the calling application is expected
&h2(DESCRIPTION)
The &cw(rmr_str2meid) function will copy the string pointed to by src to the
-managed equipment ID (meid) field in the given message.
+managed entity ID (meid) field in the given message.
The field is a fixed length, gated by the constant &cw(RMR_MAX_MEID) and if string length is larger
than this value, then &bold(nothing) will be copied. (Note, this differs slightly from the
behaviour of the &cw(lrmr_bytes2meid()) function.)
docs = config-deploy developer-guide user-guide rel-notes overview
-all:: $(docs:%=%.rst) $(docs:%=%.txt) $(docs:%=%.md)
+all:: $(docs:%=%.rst) $(docs:%=%.txt) $(docs:%=%.md)
-rel-notes.xfm:
+rel-notes.xfm: ../../../CHANGES
ksh fmt_changes.ksh >rel-notes.xfm
+# we force the docs to always be out of date so that we don't have to
+# manage the list of man pages and other files that are read to generate the
+# output needed for RTD.
+#
+$(docs:%=%.rst): always
+$(docs:%=%.txt): always
+$(docs:%=%.md): always
+
+
# copy the .rst files which have changed into the docs (plural) directory at the root of the repo
publish : $(docs:%=%.rst)
for f in *.rst;\
fi;\
done
+# just list what would be published
+verify : $(docs:%=%.rst)
+ for f in *.rst;\
+ do\
+ if ! diff -N -q $$f ../../../docs/$$f >/dev/null 2>&1;\
+ then\
+ echo "$$f would be published";\
+ fi;\
+ done
+
# ditch any intermediate files
clean:
rm -f rel-notes.xfm *.sp *.ca
nuke: clean
rm -f *.ps *.pdf *.rst *.md
+# make hack to force a rule to always be out of date
+always:
meid_map | start
mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
- mme_ar | control2 | meid100 meid101 meid102 meid103
+ mme_ar | control2 | meid100 meid101 meid102 meid103
meid_map | end | 2
meid_map | start
mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
- mme_ar | control2 | meid100 meid101 meid102 meid103
+ mme_ar | control2 | meid100 meid101 meid102 meid103
mme_del| meid200 meid401
- meid_map | end | 1
+ meid_map | end | 3
meid_map | start
mme_ar | <owner-endpoint> | <meid> [<meid>...]
mme_del | <meid> [<meid>...]
- meid_map | end | <count>
+ meid_map | end | <count> [| <md5sum>
supplied multiple times, the last observed relationship is
used. Each of the lists of MEIDs are blank separated.
+The optional <md5sum> on the *end* record should be the
+computed MD5 hash for all records which appear between the
+start and and records. This allows for a tighter verification
+that all data was received exactly as the route manager
+transmitted them.
+
Environment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
completely up to date listing of API changes.
-2019 November 14; version 1.11.1
+2019 December 9; version 1.13.1
+--------------------------------------------------------------------------------------------
+
+Correct documentation and missing rel-notes update for RTD.
+
+
+2019 December 6; version 1.13.0
+--------------------------------------------------------------------------------------------
+
+Add ability to route messages based on the MEID in a message
+combined with the message type/subscription-ID.
+
+
+
+2019 November 14; version 1.11.1 (Amber)
--------------------------------------------------------------------------------------------
Fix bug in payload reallocation function; correct length of
payload was not always copied.
-2019 November 4; version 1.11.0
+2019 November 13; version 1.12.1
+--------------------------------------------------------------------------------------------
+
+New message type constants added to support A1.
+
+
+2019 November 4; version 1.11.0 (Amber)
--------------------------------------------------------------------------------------------
Version bump to move away from the 1.10.* to distinguish
between release A and the trial.
+2019 November 7; version 1.12.0
+--------------------------------------------------------------------------------------------
+
+Version cut to support continued development for next release
+preserving the 1.11.* versions for release 1 (Amber) and
+related fixes.
+
+
2019 October 31; version 1.10.2
--------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------
The rmr_bytes2meid function will copy up to *len* butes from
-*src* to the managed equipment ID (meid) field in the
-message. The field is a fixed length, gated by the constant
+*src* to the managed entity ID (meid) field in the message.
+The field is a fixed length, gated by the constant
RMR_MAX_MEID and if len is larger than this value, only
RMR_MAX_MEID bytes will actually be copied.
DESCRIPTION
--------------------------------------------------------------------------------------------
-The rmr_get_meid function will copy the managed equipment ID
+The rmr_get_meid function will copy the managed entity ID
(meid) field from the message into the *dest* buffer provided
by the user. The buffer referenced by *dest* is assumed to be
at least RMR_MAX_MEID bytes in length. If *dest* is NULL,
--------------------------------------------------------------------------------------------
The rmr_str2meid function will copy the string pointed to by
-src to the managed equipment ID (meid) field in the given
+src to the managed entity ID (meid) field in the given
message. The field is a fixed length, gated by the constant
RMR_MAX_MEID and if string length is larger than this value,
then **nothing** will be copied. (Note, this differs slightly
}
/*
- Extracts the meid (managed equipment) from the header and copies the bytes
+ Extracts the meid (managed entity) from the header and copies the bytes
to the user supplied area. If the user supplied pointer is nil, then
a buffer will be allocated and it is the user's responsibilty to free.
A pointer is returned to the destination memory (allocated or not)