Changes between Version 10 and Version 11 of LibrariesUnderConstruction

Timestamp:

Jan 3, 2009, 9:11:22 PM (14 years ago)

Author:

viboes

Comment:

Deep description of Frames

LibrariesUnderConstruction

@@ -401 +401 @@
 == Frames  ==
  * '''Suggested by:''' Vicente J. Botet Escriba  
- * '''Description:''' in a frame library which will be based on an extension of the archive concept. The saving archive concept allows to save serializable data at the end of the archive, and the loading archive concept allows to read serializable data from the beginning of the archive. The saving frame concept will allows to save serializable data either at the end or the '''begin''' of the frame, and the loading frame concept allows to read serializable data from the beginning or the '''end''' of the archive.
+ * '''Description:''' Library based on an extension of the Archive concept making it bidirectional. 
+ 
+From wikipedia "A frame is a data packet of fixed or variable length which has been encoded by a data link layer communications protocol for digital transmission over a node-to-node link. Each frame consists of a header frame synchronization and perhaps bit synchronization, payload (useful information, or a packet at higher protocol layer) and trailer. Examples are Ethernet frames and Point-to-point protocol (PPP) frames."
+
+The Boost.serialization saving archive concept allows to save serializable data at the end of the archive, and the loading archive concept allows to read serializable data from the beginning of the archive. 
+The saving frame concept will allows to save serializable data either at the end or the '''begin''' of the frame, and the loading frame concept allows to read serializable data from the beginning or the end of the archive.
+ 
+I'm not sure which syntax will be the more appropriated. The serialization library use the <<, >>, and & operators that are associative from left to right. We need the equivalent operators from right to left. <<=, >>=, and &= seams to be the more natural candidates but I don't know if it is correct in C++ to define this operators with this prototype
+
+{{{
+#!cpp
+template <typename T> frame& operator<<=(const T&, frame&);
+template <typename T> frame& operator>>=(const T&, frame&);
+template <typename T> frame& operator&=(const T&, frame&);
+}}}
+
+{{{
+#!cpp
+h1 >>= h2 >>= sf << t2 << t1
+}}}
+
+is equivalent to
+
+{{{
+#!cpp
+(h1 >>= (h2 >>= ((sf << t2) << t1)))
+}}}
+
+and should be equivalent to
+
+{{{
+#!cpp
+sa & h1 & h2 & t2 & t1
+}}}
+
+if sf and sa were empty.
+
+The main difference is that we can do it hierarchically. The top layer will create a frame, and serialize its own information elements.
+
+{{{
+#!cpp
+frame sf;
+h_n >>= sf  << p_n << t_n;
+}}}
+
+Then this top layer will use a primitive of the lower level having as parameter the frame as payload.
+{{{
+#!cpp
+primitive_n-1(sf);
+}}}
+
+A primitive at the k level will add its own header and trailer information element to the payload of the upper level
+
+{{{
+#!cpp
+void primitive_k(frame& sf) {
+    // ...
+    h_k >>= sf  << t_k;
+    // ...
+    another_primitive_k_1(sf);
+    // ...
+}
+}}}
+
+So the frame allows to serialize top-down. To get the same result with the archive concept the serialization must be done bottom-up, needing to chain each one of the information element in a list and only when we have all off them we can start the serialization.
+I think that the frame approach should be more efficient because it avoid to store in dynamic memory the information elements to be serialized, instead they are serialized directly.
+
+Loading a frame works as loading an archive, except that we can load also at the end of the frame. This avoids to load the complete archive to load the trailer of the lower levels.
+
+{{{
+#!cpp
+lf >>= h_1;
+// ...
+t_1 << lf;
+}}}
+
+In addition, it would be great to have saving/loading frames (I'm not sure but I think that an archive can not be saving and loading at the same time). The same frame can be used as loading, analyzing only some lower levels, and as saving in order to construct other lower levels. This will be very useful for gateways and routers.
+
+{{{
+| L4 |<------------------------------>| L4 |
+| L3 |    |     ADAPTATION     |      | L3 |
+| L2 |<-->| L2 |          | X2 | <--> | X2 |
+| L1 |<-->| L1 |          | X1 | <--> | X1 |
+}}}
+
+It would be great also that the same data that can be serialized on archives, could be serializable on a frame using the same save function. But this works only when we save at the end of the frame. Let me see this using a 
+little example: Class C has 3 information elements to serialize (a, b and c). So the save 
+functions could be something like
+
+{{{
+#!cpp
+template <typename ARCHIVE>
+void C::save(ARCHIVE& sa) {
+    sa & a & b & c;
+}
+}}}
+
+This save function works well from left to right, but can not be used when saving at the beginning of a frame, because the expected result when saving at the beginning is
+
+    || a || b || c || sa ||
+
+but the result will be
+
+    || c || b || a || sa ||
+
+So unfortunately we need a different save function
+
+{{{
+#!cpp
+template <typename FRAME>
+void C::save(FRAME& sa, begin_tag&) {
+    a >>=  b >>= c >>= sa;
+    // a >>=  (b >>= (c >>= sa));
+}
+}}}
 
 ---------------------------------------------------------------------------------------------------