Updating links to the comms documentation.

Author: arobenko

howtos/howto10/README.md

@@ -37,7 +37,7 @@ consequence the limitations of the latter.
 The [tutorial5](../../tutorials/tutorial5) explains that the 
 [COMMS Library](https://github.com/commschamp/comms) implements framing
 by they "layer" classes wrapping one another, while the 
-[comms::frame::ChecksumLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1ChecksumLayer.html)
+[comms::frame::ChecksumLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1ChecksumLayer.html)
 (defined using [<checksum>](https://commschamp.github.io/commsdsl_spec/#frames-checksum) in the schema)
 wraps all the layers, checksum on which needs to be implemented. In this particular case it is only the
 `PAYLOAD`. So the wrapping looks something like that:
@@ -46,15 +46,15 @@ SYNC( SIZE( FLAGS( ID( CHECKSUM( PAYLOAD ) ) ) ) )
 ```
 Now, let's take a closer look at the `FLAGS` layer. The [<value>](https://commschamp.github.io/commsdsl_spec/#frames-value)
 definition is implemented using 
-[comms::frame::TransportValueLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1TransportValueLayer.html)
+[comms::frame::TransportValueLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1TransportValueLayer.html)
 class, which is expected to re-assign the read field's value to the message object. However, in this particular scenario
 the message object hasn't been created yet, because the `ID` information hasn't been processed yet. To help with 
 such cases the [COMMS Library](https://github.com/commschamp/comms) has compile-time
 meta-programming logic to recognize the scenario and automatically forces splitting its read operation to "until the payload" and 
 "from the payload". When such split occurs, the relevant flags field is re-assigned to message object right before the read 
 operation is forwarded to process the message payload.
 
-The [comms::frame::ChecksumLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1ChecksumLayer.html)
+The [comms::frame::ChecksumLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1ChecksumLayer.html)
 (implements [<checksum>](https://commschamp.github.io/commsdsl_spec/#frames-checksum)) on the other hand
 disallows such split of read operation to "until" and "from" payload, because in order to finalize its read operation the
 payload processing needs to be complete.
@@ -98,7 +98,7 @@ The **real** `Flags` field needs to be customized beyond the current capabilitie
 ```
 The actual code, defined in [dsl_src/include/howto10/frame/layer/Flags.h](dsl_src/include/howto10/frame/layer/Flags.h) and
 copied to [include/howto10/frame/layer/Flags.h](include/howto10/frame/layer/Flags.h) by the code generator, extends the
-[comms::frame::TransportValueLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1TransportValueLayer.html).
+[comms::frame::TransportValueLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1TransportValueLayer.html).
 ```cpp
 template<typename TField, typename TNextLayer, typename... TOptions>
 class Flags : public

howtos/howto2/README.md

@@ -31,7 +31,7 @@ The [dsl_src/include/howto2/frame/layer/IdWithSize.h](dsl_src/include/howto2/fra
 in the generated code) implements the required functionality.
 
 Due to the fact of this class is a replacement to the `<id>` layer it must extend 
-the [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html)
+the [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html)
 and implement its member functions that allow set / get of the message ID value out of the 
 field object 
 ```cpp
@@ -67,7 +67,7 @@ public:
 Note that the remaining size information is also updated inside the `prepareFieldForWrite()` member function.
 
 Now comes the tricky part. Every default layer implementation class (including 
-[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html))
+[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html))
 defines `doRead()` member function which is invoked by the `read()` and `readFieldsCached()` ones, which are used
 to drive the framing read functionality. The `doRead()` function is expected to read the field's value 
 (ID of the message), do relevant operation(s) (allocate message object) and forward the read operation to the 
@@ -127,7 +127,7 @@ public:
 };
 ```
 Once the actual remaining length (`remLen`) is known, the default `doRead()` of the base class 
-([comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html))
+([comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html))
 is invoked to properly handle the message creation, but with new length value.
 
 In order to properly test the message separation this tutorial defines `Msg1` and `Msg3` to be bound only 

howtos/howto5/README.md

@@ -89,7 +89,7 @@ The mismatch between having a single field in the `<frame>` and two separate
 fields in the `<interface>` prevents us from using standard `<value>`
 layer in the frame definition. There is a need to inject a custom
 layer code, which can still use 
-[comms::frame::TransportLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1TransportValueLayer.html) (used to implement
+[comms::frame::TransportLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1TransportValueLayer.html) (used to implement
 standard `value` layer), but with extra customization (see
 [dsl_src/include/howto5/frame/layer/VersionWithFlags.h](dsl_src/include/howto5/frame/layer/VersionWithFlags.h)).
 ```cpp
@@ -126,7 +126,7 @@ public:
 **NOTE**, that the code above uses 
 [Curiously Recurring Template Pattern](https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern) 
 to provide the base
-[comms::frame::TransportLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1TransportValueLayer.html) class with the 
+[comms::frame::TransportLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1TransportValueLayer.html) class with the 
 actual extending layer type using **comms::option::def::ExtendingClass** option.
 
 In addition it overrides the default implementation of the **reassignFieldValueToMsg()**

howtos/howto6/README.md

@@ -78,7 +78,7 @@ copied to the protocol definition
 by the code generator.
 
 The `Checksum` layer is implemented by extending the 
-[comms::frame::ChecksumLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1ChecksumLayer.html)
+[comms::frame::ChecksumLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1ChecksumLayer.html)
 class provided by the [COMMS Library](https://github.com/commschamp/comms), and
 customizing various operations.
 ```cpp
@@ -99,7 +99,7 @@ class Checksum : public
 **NOTE**, that the code above uses 
 [Curiously Recurring Template Pattern](https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern) 
 to provide the base
-[comms::frame::ChecksumLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1ChecksumLayer.html) class with the 
+[comms::frame::ChecksumLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1ChecksumLayer.html) class with the 
 actual extending layer type using **comms::option::def::ExtendingClass** option. It makes the customization 
 of the default operations possible.
 

howtos/howto7/README.md

@@ -36,7 +36,7 @@ by the code generator.
 
 The [AlternatingSync](dsl_src/include/howto7/frame/layer/AlternatingSync.h) layer
 is implemented by extending 
-[comms::frame::SyncPrefixLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1SyncPrefixLayer.html).
+[comms::frame::SyncPrefixLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1SyncPrefixLayer.html).
 ```cpp
 template<typename TField, typename TNextLayer, typename... TOptions>
 class AlternatingSync : public
@@ -55,7 +55,7 @@ class AlternatingSync : public
 **NOTE**, that the code above uses 
 [Curiously Recurring Template Pattern](https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern) 
 to provide the base
-[comms::frame::SyncPrefixLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1SyncPrefixLayer.html) class with the 
+[comms::frame::SyncPrefixLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1SyncPrefixLayer.html) class with the 
 actual extending layer type using **comms::option::def::ExtendingClass** option. It makes the customization 
 of the default operations possible.
 

howtos/howto8/README.md

@@ -63,7 +63,7 @@ and the `Flags` layer is implemented inside
 (copied by the code generator to [include/howto8/frame/layer/Flags.h](include/howto8/frame/layer/Flags.h))
 
 The [Id](dsl_src/include/howto8/frame/layer/Id.h) is implemented by extending
-and customizing [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html).
+and customizing [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html).
 ```cpp
 template<typename TField, typename TMessage, typename TAllMessages, typename TNextLayer, typename... TOptions>
 class Id : public
@@ -112,22 +112,22 @@ public:
 };
 ```
 **NOTE** that the inner (wrapped) layers like `Flags` can be accessed using a 
-sequence of [nextLayer()](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html)
+sequence of [nextLayer()](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html)
 member functions invocations (`Base::nextLayer().nextLayer().nextLayer()....`). 
 In this case the `Flags` is actually the next one and only single invocation needs to be used.
 
 The `Flags` layer class is also expected to provide `setFieldPreset()` and 
 `isFieldPresent()` member functions.
 
 For more details on available customization of the 
-[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html)
+[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html)
 please refer to 
 [Defining Custom Message ID Frame Layer](https://commschamp.github.io/comms_doc/page_custom_id_layer.html)
 COMMS library tutorial page.
 
 The [Flags](dsl_src/include/howto8/frame/layer/Flags.h) is implemented by extending
 and customizing 
-[comms::frame::TransportValueLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1TransportValueLayer.html).
+[comms::frame::TransportValueLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1TransportValueLayer.html).
 ```cpp
 template<typename TField, typename TNextLayer, typename... TOptions>
 class Flags : public
@@ -211,7 +211,7 @@ The write operation is performed normally due to the mode preparation is done in
 the `prepareFieldForWrite()`.
 
 For more details on available customization of the 
-[comms::frame::TransportValueLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1TransportValueLayer.html)
+[comms::frame::TransportValueLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1TransportValueLayer.html)
 please refer to 
 [Defining Custom Transport Value Frame Layer](https://commschamp.github.io/comms_doc/page_custom_transport_value_layer.html)
 COMMS library tutorial page.

howtos/howto9/README.md

@@ -38,7 +38,7 @@ and copied to the protocol definition
 ([include/howto9/frame/layer/Checksum.h](include/howto9/frame/layer/Checksum.h)) 
 by the code generator.
 
-It extends [comms::frame::ChecksumPrefixLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1ChecksumPrefixLayer.html)
+It extends [comms::frame::ChecksumPrefixLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1ChecksumPrefixLayer.html)
 because the checksum field is located before the message payload.
 
 Also note the usage of 
@@ -62,10 +62,10 @@ class Checksum : public
 ```
 
 The default implementation of the checksum calculation functionality inside the 
-[comms::frame::ChecksumPrefixLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1ChecksumPrefixLayer.html)
+[comms::frame::ChecksumPrefixLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1ChecksumPrefixLayer.html)
 proceeds forward to the payload calculation. However, the protocol specification demands calculation of the checksum on
 the preceding framing header instead. The customization of the default behaviour is possible by overriding the 
-[comms::frame::ChecksumPrefixLayer::calculateChecksum()](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1ChecksumPrefixLayer.html) member function.
+[comms::frame::ChecksumPrefixLayer::calculateChecksum()](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1ChecksumPrefixLayer.html) member function.
 ```cpp
 template<typename TField, typename TNextLayer, typename... TOptions>
 class Checksum : public comms::frame::ChecksumPrefixLayer<...>

tutorials/tutorial11/README.md

@@ -50,22 +50,22 @@ may be created. To avoid that there is a need to request "static-binary-search"
 process as well. In order to understand how to do it there is a need to dive a little bit into the 
 [COMMS Library](https://github.com/commschamp/comms) internals.
 
-The framing uses [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html)
+The framing uses [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html)
 which is responsible to read received numeric message ID and create appropriate message object.
 In order to create such object the 
-[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html)
+[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html)
 contains [comms::MsgFactory](https://commschamp.github.io/comms_doc/classcomms_1_1MsgFactory.html) in its
 private data members. The 
 contained [comms::MsgFactory](https://commschamp.github.io/comms_doc/classcomms_1_1MsgFactory.html)
 can be configured to use appropriate dispatch logic via its options. The relevant options are:
 `comms::option::app::ForceDispatchPolymorphic`, `comms::option::app::ForceDispatchStaticBinSearch`, or 
 `comms::option::app::ForceDispatchLinearSwitch`. The 
-[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html) 
+[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html) 
 has its own supported options which it processes. The ones it doesn't expect are passed to the 
 [comms::MsgFactory](https://commschamp.github.io/comms_doc/classcomms_1_1MsgFactory.html).
 It means in order to avoid creation of virtual functions inside 
 [comms::MsgFactory](https://commschamp.github.io/comms_doc/classcomms_1_1MsgFactory.html) the
-[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html) 
+[comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html) 
 needs to receive `comms::option::app::ForceDispatchStaticBinSearch` option.
 
 The used `Frame` inside the [include/tutorial11/frame/Frame.h](include/tutorial11/frame/Frame.h) is defined
@@ -192,7 +192,7 @@ private:
 Another curious thing to notice is a lack of virtual destructor for the common message interface 
 class (due to the lack of any polymorphic behaviour). During the `read()` operation the frame 
 dynamically allocates proper message object and holds it by the `std::unique_ptr` to the 
-**common message interface** class (see [Frame::MsgPtr](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1ProtocolLayerBase.html)). 
+**common message interface** class (see [Frame::MsgPtr](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1ProtocolLayerBase.html)). 
 After reading these statements any experienced C++ developer should scream about 
 incorrect message destruction and potential memory leaks. **HOWEVER**, this is not the case
 with the [COMMS Library](https://github.com/commschamp/comms). It 
@@ -319,11 +319,11 @@ std::size_t ClientSession::processInputImpl(const std::uint8_t* buf, std::size_t
   to the common message interface class, but with a custom deleter which insures
   correct destruction and de-allocation of the object.
 - The framing layer responsible for allocation of the message object is 
-  [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html), which
+  [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html), which
   uses [comms::MsgFactory](https://commschamp.github.io/comms_doc/classcomms_1_1MsgFactory.html) in its 
   private data members to allocate appropriate message object when the ID value is known.
 - The message allocation options passed to the 
-  [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1protocol_1_1MsgIdLayer.html) are
+  [comms::frame::MsgIdLayer](https://commschamp.github.io/comms_doc/classcomms_1_1frame_1_1MsgIdLayer.html) are
   also forwarded to [comms::MsgFactory](https://commschamp.github.io/comms_doc/classcomms_1_1MsgFactory.html). They
   can be used to force a particular dispatch policy for mapping numeric message ID into the message type.
 - In order to forcefully avoid generation on polymorphic dispatch table inside