GSoC Idea: Common (De)Serialization Infrastructure

GSoC Idea: Common (De)Serialization Infrastructure

Areas (De)serialization, RPC
Good if student knows Tcl, C
Priority Medium to Low
Difficulty Medium to High
Benefits to the student Learning about data serialization, the challenges therein.
Benefits to Tcl Enhanced ability to exchange data with other languages
Mentor AK, others
Related Projects & Ideas GSoC Idea: Tcl Binding to Protocol Buffers
GSoC Idea: Tcl Binding to MessagePack
GSoC Idea: Updated Tcl bindings for ZeroMQ
Tcl YAML
STOMP

Project Description

We currently have three possibilities of handling the (de)serialization of Tcl data structures to other formats. The main constraint in the design is that most (all?) (de)serialization formats around are (strongly) typed, whereas Tcl's basic data structures are not.

The main ways of dealing with this impedance mismatch are:

  1. Inbound map the serialized data to simple Tcl data structures, and ignore the type information. Outbound then requires constructor commands and/or additional data structures describing the data to generate and providing the necessary type information, implicitly or explicitly.
  2. Inbound map the serialized data to simple Tcl data structures, but keep the type information somehow, for example as type tags. Outbound a generic converter can then directly serialize such a type-tagged structure without the need for helper structures.
  3. Fill out: TclOO structures mimicking simple Tcl structures and other types, with accessor methods.

Each of these methods has their own advantages and disadvantages.

Examples of both (1) and (2) can be found in Tcl YAML , with (1) using separate type description data structures.

The pair of json and json::write packages of Tcllib are another example of (1), using constructor commands on the outbound side.

Regarding approach (3) I am not aware of existing examples.

This is what I am interested in here, with this idea. If that is a feasible approach, and if yes, what are its (dis)advantages ?

References

  • to be filled in.

Comments & Discussion

SEH -- FWIW, I use Metakit when I need to serialize data from a Tcl program into a type-aware external format. I have written a JSON exporter that automatically converts the contents of a Metakit view to a JSON string. The view is initialized using Metakit's simple schema format for specifying types. The JSON exporter uses Metakit's introspection features to determine the type of each field and construct the corresponding JSON string appropriately. Metakit has the additional advantage of supporting sub-views, so a hierarchically-structured JSON string can be constructed from a view and its subviews.

If a pure-Tcl solution is a must-have, maybe a Metakit-type approach could be used as design inspiration.


mocallins - 2025-10-23 16:01:42

I too agree that the current possibilites are restrictive, i.e. YAML, JSON, XML

I'd love to see a NOT strongly typed solution, or as i would term it, more TCL centric.

Hmmm aren't we capable of leveraging some of the best concepts from other formats but enhanced, mainly for TCL but if its done right, maybe for the whole world.

I love the YAML layout, not having to have a character at the end of every line, like ',' (JSON) but hate the indentations (strongly typed), XML doesn't have this problem, but hate the special tag '<element>' syntax Also don't like having to escape characters, most notably '/', or '\\', just horrid, the actual interpreter being used, figure it out, or add a setOption on how to deal with them.

Lets use the TCL approach EVERYTHING is a string, no special mucking happening, using "null" and it show up as nothing in the actual converted data, just let it be null, or have a setOption to convert it to a nothing if desired.

And more TCL centric you can use bracketed expressions '[info hostname]' and have that be interpreted, makes me think of 'subst' with its options. Again seems like 'setOpions' could deal with that as well

I think its completely doable, and the trick i think is in understanding how the ':' separator works. if there's nothing after it, on a line, then its a 'container' that everything after, is what WOULD be indented. if there's data after the ':' its an element (key:value pair).

Also love the YEML notation with "-" at the front, defines all the following "-" options as a list elements (array)

No restrictions on using spaces in the key, or value. Whatever you are intending on using it for, deal with it to make it work for you.

My current attempted usage, was with some MQTT, YAML allowed the space, in the value, but i couldn't seem to get it to act right, in the publish/subscribe topic. But was enough to deal with, take the space out, was sent flawlwessly.

Just my opinions,don't know about all the other possible restrictions, just seems doable.


mocallins - 2025-10-24 14:54:50

Okay, so i got bored and still was thinking about this, so i started simple and hacked out some code. Then expanded on it. Still needs some work, but i think the basic parsing is there.

package provide tclml 0.1

# lol, no better name TCL Markup language (tclml)

namespace eval tclml {

  proc parse {fname} {

    set fh [open $fname r]

    set parents ""

    while {![eof $fh]} {

      set rl [gets $fh]
      if {$rl == ""} {continue}

      lassign [split $rl {:}] key val

      set indent [regexp -nocase -- {^\s+} $key]

      set key [string trim $key]

      if {[info exists val] && $val == ""} {
        lappend parents $key
        continue
      }

      set val [string trim $val]

      if {$parents == ""} {
        dict set retVal $key $val
      } else {
        if {$indent} {
          set parent [lindex $parents end]
          dict set $parent $key $val
        } else {
          set parent [lindex $parents end]
          set parents [lrange $parents 0 end-1]
          dict set retVal $parent [set $parent]
          unset $parent
          dict set retVal $key $val
        }
      }

    }
    
    foreach elm $parents {
      set parent [lindex $parents end]
      set parents [lrange $parents 0 end-1]
      dict set retVal $parent [set $parent]
    }

    return $retVal

  }

}

the input i used developing / testing:

[pimo]:</home/pi/> cat test.tml

parent1 :
  key1 : val1
  parent2:
          key2 : val2


key3 : val3
      key4: val4 plus other junk {} []
null: null
true    : True
False  : false

test 1 2 3:
  val1: 4 5 6

and the printed out dictionary:

test is dict:
parent2 {
          key2 val2
        }
key3 val3
parent1 {
          key1 val1
          key4 {
                 val4 plus
                 other junk
                 {
                  }
                 []
               }
        }
null null
true True
False false
{
   test 1
   2 3
 }
{
   val1 {
          4 5
          6
        }
 }

Sorry Andreas if this is not the place to put this. Please remove and post somewhere appropriate.