Ivyware Msgcore Structured message store Implemented in C++ since 2000 Melbourne, AU
Ivyware

Ivyware/Msgcore

Msgcore — the structured message store

One heap.
Every field addressed.
Nothing to serialise.

A store manager owns a single heap. Named fields, their values, their children, their @-qualified attributes and the list, vector, stack and cursor containers over them all live inside that one heap and are addressed by offset, not pointer. The store is therefore one contiguous image — write it to a file, read it back, and there is no serialisation pass and no pointer fix-up in between. Msgcore has been doing this since 2000.

Watch the heap grow → Component reference Libraries & downloads
One heap, offset-addressed, saved verbatim WHAT YOU WRITE Settings ROOT FIELD window x = 1240 y = 820 @units = px ATTRIBUTE ALLOCATE WHAT IT IS P2PMSGMGR — ONE HEAP Settings window x y @u 0 +64 +128 +180 +232 OFFSETS — NOT POINTERS growth moves the base → offsets survive NO FIX-UP PASS ANYWHERE IN THE LIBRARY WHERE IT GOES settings.p2p SAME BYTES, ATOMIC RENAME P2Piomage THE FRAME TARGETCORE MOVES
One heap · offset addressing · the same image on disk and on the wire
2000Store in service since
0Serialisation passes to save
282Flat C entry points
1Heap per store, one image

Six lines, and the store is on disk

The whole idea

There is no schema to declare, no writer to configure and no serialiser to call. A field is created inside the manager's heap; saving copies that heap out, and loading maps it back.

C++ — create, save, load

#include "P2PmsgMgr.h"

P2PmsgMgr mgr;
mgr.r_name() = _N("Settings");
mgr.r_Desc() += P3PmsgField ( L"window" );
mgr.Save ( L"settings.p2p" );   // atomic: temp file, then rename over the target

P2PmsgMgr load;
load.Load ( L"settings.p2p" );   // read-only, shared, header-validated

Watch the heap grow

Five fields go into one heap. The fifth does not fit, so the heap reallocates its base and copies — and every offset in the image is still correct, because none of them ever named an address. Then the whole thing is written to disk as the bytes it already is.

WHAT YOU WRITE Settings ROOT FIELD window x = 1240 y = 820 @units = px ATTRIBUTE · BESIDE THE CHILDREN A NODE IS A PATH, NOT A POINTER WHAT IT IS P2PMSGMGR — ONE HEAP OLD ARENA · FREED Settings 0 window +64 x +128 y +180 @units +232 OFFSETS — DISPLACEMENTS FROM THE BASE base = 0x7F3A_1000 THE ONLY ADDRESS ANYWHERE IN THE STORE growth: new base, copied image, same offsets no fix-up pass anywhere in the library a cached raw pointer is the one thing that dangles GROWTH · FREE LIST · ENDIAN SENTINEL · LAYOUT GENERATION WHERE IT GOES settings.p2p SAME BYTES · TEMP FILE · RENAME same sha256 · Windows + Linux Load READ-ONLY · SHARED · VALIDATED over-declared → refused

Caller code


        

        

          
Inside the manager

          

        

      

    

  








  

    
What the store gives you

    Design properties
  

  

    

      
Addressing

      
Offsets, not pointers

      
Every reference inside the store is a displacement from the base of the heap. Growth reallocates that base — and every reference in the image is still correct, because none of them named an address in the first place.

    

    

      
Persistence

      
Save is a copy

      
The store is already contiguous and already self-describing, so writing it is writing bytes. Save goes to a temporary file and renames over the target, so a reader never sees a half-written store.

    

    

      
Shape

      
Fields, children, attributes

      
A field carries a name, a typed value, an ordered set of children and a set of @-qualified attributes. Native types, strings, blobs, XML and images all live in the one structure, addressed by field and by path.

    

    

      
Containers

      
Lists, vectors, stacks, cursors

      
The container types are not adapters over the store; they are laid out inside its heap. A cursor survives mutation of the ring it is scanning, which is what makes by-name traversal of a live store workable.

    

    

      
Portability

      
One image, two widths

      
An endian sentinel travels with every image and doubles as its layout generation, so a store written under one byte order or addressing width is recognised — rather than silently misread — by another.

    

    

      
Reach

      
C++, C, Java, COM

      
A C++ class API for code built with the same toolset, and a flat extern "C" ABI of 282 entry points for everyone else — C, Java through Panama, .NET through P/Invoke, FUSE front ends. MsgFacade wraps the object model without macros, and MsgcoreCom puts a store one CreateObject away from PowerShell, VBScript and C#. See the facade page.

    

    

      
Diagnostics

      
One event system

      
P2Pevent carries errors and diagnostics as throwable C++ exceptions, or as data attached to a store — the same object TargetCore routes across a network.

    

    
    

      
Scope

      
What it is not

      
The store is not internally synchronised — one store is serialised by its caller — and it has not been reviewed as a network-facing parser. Treat an image from a source you do not control as unsafe to load.

    

  






  

    
Two libraries, one lineage

    How they fit
  

  
Msgcore and TargetCore are separate products with a one-way dependency. Msgcore knows nothing about networks; TargetCore does not define a payload format.

  

    
MsgcoreDefines the store, the fields and the P2Piomage frame. In service since 2000.

    
TargetCoreAddresses, encrypts and moves that frame between hubs. In service since 2002.

    
The ruleMsgcore does not depend on TargetCore. The layering is acyclic, and always has been.

    
In practiceThe message you build with Msgcore is the message a hub routes. There is no conversion step.

  

  

    The type reference →
    TargetCore walkthrough
  






  

    
The pieces

    Type model
  

  
Seven families carry the whole store. The full reference — the containers, the flat C ABI and the two rules a caller has to honour — is on the architecture page.

  

    

      Msgcore type families
      
        
TypeResponsibility

      
      
        
P2PmsgMgrThe store manager. Owns the heap, the root field, the save and load paths, path lookup and triggers.

        
P3PmsgFieldA named node: a value, an ordered set of children, and a set of attributes. The unit everything else is built from.

        
P3PmsgDataThe typed value a field holds — native types, strings, BSTRs, blobs, XML and images.

        
MsgVBHeapThe offset-addressed heap and its block allocator: growth, the free list, and the addressing widths.

        
MsgList · MsgVect · MsgStck · MsgCursThe container types over a field's children, laid out inside the heap rather than over it.

        
P3PmsgBSTR · P2PiomageString storage, and the packed sync-header frame that leaves the process — the shape TargetCore encrypts and moves.

        
P2PeventEvents and exceptions. Throwable, attachable to a store, and shared with TargetCore.

      
    

  

  

    Full architecture →
    Downloads
  






  

    
Built on it

    In production
  

  

    
      
Library

      
TargetCore

      
The routing kernel. Every message a hub queues, encrypts and dispatches is a Msgcore image; the kernel adds the address, the wire and the handler map.

      See the walkthrough →
    
    
      
Application

      
Chartboard

      
Workspaces, chart stacks, portfolios and scanner results are stores — which is why a workspace file loads without a parse and a chart survives a round trip intact.

      Explore Chartboard →
    
    
      
Reference server

      
AKAserva

      
An HTTP and WebSocket server where a parsed request is a field tree, decorated by handlers and translated back into a response.

      Read more →