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

Hi, 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." Is there any interest 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 begining 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 begining or the *end* of the archive. I'm not sure which syntax will be the more adequated. 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 adequated candidates but I don't know if it is correct in C++ to define this operators with this prototype template <typename T> frame& operator<<=(const T&, frame&); template <typename T> frame& operator>>=(const T&, frame&); template <typename T> frame& operator&=(const T&, frame&); h1 >>= h2 >>= sf << t2 << t1 ~ (h1 >>= (h2 >>= ((sf << t2) << t1))) sould be equivalent to 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. 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. 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 void primitive_k(frame& sf) { // ... h_k >>= sf << t_k; // ... another_primitive_k_1(sf); // ... } So the frame allows to serialize top-down. 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. lf >>= h_1; // ... t_1 << lf; In addition, it would be greate 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 greate 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 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 begining of a frame, because the expected result when saving at the begining is | a | b | c | sa | but the result will be | c | b | a | sa | So unhappylly we need a different save function template <typename FRAME> void C::save(FRAME& sa, begin_tag&) { a >>= b >>= c >>= sa; // a >>= (b >>= (c >>= sa)); } Please let me know if you are interested in such a library, and what are your requirements. Robert, do you think that this can be seen as an extension of the serialization library? Best regards, Vicente Juan Botet Escriba