After some experimentation with Jonathan Wakely’s pstreams library (http://pstreams.sourceforge.net/), i’ve got deserialization over http, ftp, and ssh working, as well as serialization over ssh. The support works by mapping URL protocols to classes which wrap up protocol-specific support over the pstreams i/ostreams. For example, saving a file to ssh://me@host:/path/to/file will save the file using the ssh application to make the connection. Likewise, loading from that same URL would use ssh to read the file. The http/ftp support is currently handled by wget, but adding a curl (or other) wrapper is straightforward.
This code won’t go into the core library, mainly because it is LGPL but also because it’s very Unix-centric. However, once some more design decisions are figured out i hope to create a plugin which provides this support via the s11nlite API.
It’s been over a month since the release of s11n 1.2.3, and we’ve made only one minor bugfix since then (hardly worth making a release for, because it just adds “::std::” to s11n.net/s11n/proxy/std/multimap.hpp). So what’s next?
The truth is, i haven’t much of an idea. i’ve been reading “C++ Template Metaprogramming” lately, a book written by David Abrahams (one of the Boost founders). While the book is missing some details i would like to have seen explicitely explained, it does contain everything one needs to get a good grasp of advanced template-based programming. Some of the techniques they demonstrate would certainly be of use in the context of serialization. For example, their type containers (fundamentally similar to Alexandrescu’s TypeLists) are theoretically useful for building up serialization algorithms for disparate types via functional composition. Building upon that we may be able to make the construction of de/serialization algorithms simpler. The down-side is that in order to perceive such a change as a simplification, one has to have a good understanding of how template metaprogramming works. Since that is a fairly advanced C++ topic in and of itself, i’m not yet fully convinced that we can achieve many simplifications using those techniques. Rather, we’d be trading one type of complexity for another.
In any case, if you use s11n and have any ideas on how we might improve future versions, please get in touch via our development list, firstname.lastname@example.org.