reinstate Thing class doc

Author: VigneshVSV

docs/beginners-guide/articles/thing/index.md

@@ -4,7 +4,7 @@
 
 A default logger with IO stream handler is configured for each `Thing` instance. One can override the logger by passing a custom logger instance to the `Thing` constructor:
 
-```py title="Custom Logger" linenums="1" hl_lines="3"
+```py title="Custom Logger" linenums="1" hl_lines="12"
 class WarningsToFileHandler(logging.FileHandler):
     """Custom handler that writes only WARNING+ logs to a separate file."""
     def emit(self, record):
@@ -48,9 +48,16 @@ Endpoint | Description
 `http(s)://<host>:<port>/<thing_id>/logger/logs` | all logs
 `http(s)://<host>:<port>/<thing_id>/logger/logs/debug` | debug logs and above -->
 
+### Meta
+
+To be updated with use cases of modifying Thing metaclass, in the meanwhile there is decent documentation in
+the developer notes: [Thing MetaClass](../../../design/metaclasses.md#metaclasses).
+
 ### Post Init
 
-`Thing` classes define a `__post_init__` method which is invoked after loading properties from a database.
+To be updated, please refer to the developer notes in the meantime: [Thing Post Init](../../../design/metaclasses.md#__post_init__-method).
+
+<!-- `Thing` classes define a `__post_init__` method which is invoked after loading properties from a database.
 All initialization logic which depend on database loaded properties can placed in this method:
 
 ```py title="Post Init" linenums="1"
@@ -61,11 +68,8 @@ class MyThing(Thing):
         super().__post_init__() # dont forget to call parent
         self.logger.info("Thing initialized with properties from DB")
 ```
-
-### Meta
-
-To be updated with use cases of modifying Thing metaclass.
+-->
 
 ### Composition
 
-To be updated with using sub-things within a Thing.
+To be updated.

docs/design/metaclasses.md

@@ -42,12 +42,12 @@ class CameraMeta(ThingMeta):
 class Image(Property):
 
     def __init__(self,
-                compression_ratio: int = 1,
-                transpose: bool = False,
-                flip_horizontal: bool = False,
-                flip_vertical: bool = False,
-                observable: bool = False,
-            ) -> None:
+            compression_ratio: int = 1,
+            transpose: bool = False,
+            flip_horizontal: bool = False,
+            flip_vertical: bool = False,
+            observable: bool = False,
+        ) -> None:
         ...
 
 class RPiCamera(Thing, metaclass=CameraMeta):
@@ -65,7 +65,7 @@ class IDSCamera(Thing, metaclass=CameraMeta):
 
 ## `__post_init__` Method
 
-There is no specific need to explicitly call a `__post_init__` method. A possible application of `__post_init__` could be to run default code after connecting to the hardware:
+There is no specific need to explicitly call a `__post_init__` method as it is auto-invoked by the [`ThingMeta`](../api-reference/thing/thing-meta.md). A possible application of `__post_init__` could be to run default code after connecting to the hardware:
 
 ```python
 
@@ -93,4 +93,4 @@ flowchart TD
     D --> E[__post_init__ is called to run additional setup code <br/>which are dependent on the loaded properties]
 ```
 
-Of course, the `__post_init__` method can be used for any other purpose. The `__post_init__` is auto-invoked by the [`ThingMeta`](../api-reference/thing/thing-meta.md).
+Of course, the `__post_init__` method can be used for any other purpose.

docs/design/zmq.md

@@ -4,8 +4,8 @@ The main purpose of the RPC broker is to:
 
 - add scheduling control for the interaction affordances
 - decouple protocol handlers (a.k.a controllers) from the actual execution of the interaction affordances
-- unify execution control across multiple protocols
-- maintain standardized behaviour irrespective of the protocol, for example, pushing an event must cause both the HTTP and MQTT clients to receive the same event
+- unify execution across multiple protocols
+- maintain standardized behaviour irrespective of the protocol, for example, pushing an event must cause both a HTTP and a MQTT client to receive the same event
 
 Three types of scheduling are supported:
 
@@ -35,7 +35,7 @@ sequenceDiagram
     ProtocolHandler-->>Client: Forward Event (Pub, protocol specific)
 ```
 
-In a certain way, this is definitely a protocol-to-protocol transfer of request and response, with a minor difference that ZMQ handles this over its `INPROC` transport over threads & shared memory, which is significantly more efficient than TCP-to-TCP communication.
+In a certain way, this is definitely a protocol-to-protocol transfer of request and response, with a minor difference that ZMQ handles this over its `INPROC` transport over threads & shared memory, which is significantly more efficient than TCP-to-TCP communication & adds very little overhead.
 
 The scheduling message is a simple JSON object, tailored to arbitrary serialization and ZMQ multipart messaging scheme: