s11n 1.1: what are the plans?

This page covers plans for the 1.1 development branch of libs11n. Once 1.1 stabilizes it will become 1.2... etc., etc. The current guesstimation of a release date for 1.2 is Q4 2005.

1.1 can be downloaded from the downloads page, as can the library manual.

1.1 is architecturally almost identical to 1.0, but it has been restructured and refactored, primarily in the name of having a more portable source tree. It also provides a number of leak guarantees which 1.0 does not correctly impose (and cannot without significant changes).

In no particular order, the significant changes, planned changes, and wishes for 1.1/1.2 include...

s11nlite refactoring

s11nlite's interface won't change much, but it is now refactored to live on top of a class, client_api<NodeType>. The purpose of this is to allow client code to very easily create their own variant of s11nlite by simply templatizing the type client_api<NodeType[,SerializerInterface]> to suit their needs, or via subclassing. s11nlite allows clients to plug in their own type, as long as it uses the same node type as s11nlite. See the sample under src/client/sample/mylite.cpp

Header file re-orgs

Many of the current headers have their names for historical - not practical - purposes. At one point i had two completely different s11n architectures living in the same source directory, and had to differentiate their header file names. (i needed it to allow my s11n 0.6-based client code to work.) Many headers have been moved around, in particular the proxy-related headers have been reorganized to be easier to find.

P::Classes: P::s11n

i am working with the "P" team on rewriting their framework for their 2.0 release. Part of that rewrite includes porting in a fork of the core libs11n features. Both trees will learn from each other. For details on what support this will provide, see the ps11n page. We get some very exciting features via cross-breeding P and s11n.

Platform portability improvements

Part of P::Classes' focus is platform portability. While these 2 projects will not merge, and will have no direct dependencies on each other, i will adapt some of their platform-portability design techniques into s11n.

As of version 1.1.2+ we can build under Windows :).

Factory rewrite

i've rewritten the underlying factory (classloader) layer from scratch. i won't say it's any better or worse, just a bit different. This won't affect the majority of client code, since s11n provides an abstraction API into the classloader in the first place.

Virtual device tree

During the P refactoring we came up with an interesting use for a classloader: a virtual filesystem (or object system). Consider these calls to factories:


mycompany::MyObj * obj = Factory<mycompany::MyInterface>
        ::instance().( "/mycompany/mylib/MyClass" );
SerializerT * obj = Factory<SerializerT>
        ::instance().( "/s11n.net/s11n/io/serializers/DefaultOutputSerializer" );

i already have plans to use this approach for defining some of the internally-used lookup keys, to provide a consistent way for clients to get at them.

The interesting bit is that nothing changes - the factory already supports this, but this is simply another way of looking at factory lookup keys. With a bit more work we could implement path parsing and turn it into a real registry-style object database.

What would that change in s11n? Very little, if anything - it would just be interesting to experiment with.

And let's not forget...

What would you like to see changed?

Main menu:

Download from:

Libs/apps/utils:

SourceForge:

More Resources:

Related sites: