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:
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.
- 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,
- 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 :/.