Serialization made simple.
Project powered by:

libs11n 1.4.x

This page covers s11n 1.4, which is currently in development and will be called 1.3.x until it is mature enough to release at a stable version, at which point it will be renamed to 1.4. If you need a stable, working library right now, please use version 1.2.

Version 1.4 is currently effectively the same as 1.2, but adds a few features and has some significant changes planned.

The head of the SVN tree is always the latest development branch, which you can pull using a Subversion client using this command:
svn co https://s11n.svn.sourceforge.net/svnroot/s11n/trunk s11n-head

Main differences from version 1.2:

  • Support for handling URLs, meaning that it can read/write using URL sources/targets if a handler can be found for dealing with that URL scheme. i believe s11n is the first serialization library ever which can save objects directly to email :). The underlying support for this feature will likely undergo significant changes before the 1.4 release, however.
  • Desired, but still a long way of, is a re-working of the string/stream support so that s11n is not hard-coded to use narrow characters. This will allow it to natively support wide characters and custom string types (e.g. project-specific UTF16 string types). The major problem here is that this requires completely reimplementing all of the Serializers (i/o handlers), which is a huge (and exceedingly tedious) undertaking. After initial experimentation it was found that not only are the i/o handlers affected, but also the classloader layer (because the lookup keys are strings). This particular aspect is probably the most problematic, because the classloader is largely independent of s11n's internals, and we have no straightforward way to get the char_type information over into the classloader. It also makes the current classloader registration technique useless, because the varying char_types make it impossible(?) to uniformly pass strings to the registration supermacros.
    In retrospect it would probably be less work to fork a separate copy of the core s11n library for each string type :/.
Due to Real Life getting in the way, a 1.4 release is still a long way off, in any case (probably 2010), so these goals may be revised (several times) before then.