A word about serialization (Re: [Chicken-users] s11n + rpc)

[felix winkelmann]

Some technical information about the current implementation
of serialization may be in order:

As long as no procedures or continuations are serializated,
it shouldn't be too hard to add more robustness and portability
to its format. But once procedures enter the scene things
can get so ugly, that I ask me whether it makes sense to
actually even try to approach portability.
Currently, when chicken is configured with --enable-procedure-tables,
a static array is generated for each file/unit that holds a string ID
(made from the internal "lambda"-ID, which is locally unique and
the source file-name) and a void* to the procedure/continuation
code. Compiling the same file with different compiler versions,
compiler options or only a few procedures more or less will
shift the lambda-ID counter arbitrary, so any serialized data
refering to the older set of IDs will not work or worse, will work
and fail for weird reasons. Now, one could go to great lengths
about ensuring more robustness here, but I wonder if it's worth
the trouble.
As long as serialization is used for quick, local, short-range
communiation, or communication of a rigidly controlled set of
machines one might be able to handle the needed steps of
keeping the code-base in sync. Another example is locally
storing session-data (i.e. web-servers).
But for larger-scale communication, or communication across
a heterogenous network, I highly recommend S-expressions,
which are just as portable as XML, but need less bandwidth
(and are easier to parse).


cheers,
felix