Receiving updates on shared segments

Consent manager deals with incoming messages of the type:

NodeMsg node_name seg_name seg_data...;

This is all args list, and the seg_name is unique in context and namesapce.  Both holders of shared segments and the node array treats seg_name as unique overt the current  consent network.

It is unique in context, it can be a call back at the local level:

name_seg seg_data;  # Execute a sub command in the caller entry point

In this last contest, the consent snippet, upon receiving its notification, need not move the data, sockets snippet left it as received on args, so consent does:

 *argc++; 
ExecCommand(argc,args); 
return(SUCCESS);

The is no need to marshal call arguments, leave them. For consistent sql_lite table across the enterprise, sql_lite does not play a role, except to expose its api across a universal interfaces. Parties at the terminal end of the consent network are executing transparently across the normal,  universal interface.

 All of this is set up by data manager, it is she who knows which tables need to be consistent.  It is arranged by an enterprise semantic tool, likely a Go or Python enterprise semantic manager. Via that tool namespace is laid out to prevent name conflicts, and direct the future paths of data flow. Meanwhile enterprise semantics takes a great load off of the snippets, as they can simple pull the abort switch on namespace error.