[pclasses-devel] notes on P vis-a-vis s11n

[stephan b. <st...@s1...>]

Hi again,

i wanted to take a minute to "preach" - to give some insights on the 
possibilities of mixing s11n and P together, and how that might be 
accomplished with remarkably little effort.

As you may have noticed, based on the size of the s11n documentation and 
web site, i'm Very Proud of s11n. Over the past 14 months it has 
evolved to do every serialization task i've thrown at it (with one 
small exception, but i'm working on solving that). It hasn't yet been 
used for network-based serialization, as far as i know, but with P i 
hope to change that.

s11n takes a slightly unconventional approach to integrating into 
projects: instead of forcing a project to use s11n's API directly, s11n 
can be told to follow a client-side API, via the use of proxies created 
via class template specializations and functors. What this essentially 
means is that we can seemlessly, for purposes of the API, merge s11n 
and P. i would be more than happy to take on this work, and to assist 
with P in any way that i can.

s11n comes with a layer called 's11nlite'. This layer provides a binding 
between the core s11n layer (which is 100% container-based - no streams 
support) and the reference implementation of an i/o layer (s11n::io). 
s11nlite contains a relatively small amount of code, encapsulated in 1 
header and 1 impl file.

Now, with a little bit of copy/paste work it would be no problem at all 
to provide a P-centric version of s11nlite, like P::s11n, which hides 
the "raw" s11n API from P applications. That is, clients would not have 
to know they're using 2 different frameworks when serializing their P 
objects via s11n. The best part is: this can be done a) without 
modifying s11n and b) without modifying (only adding to) P.

i suspect that a lot of the "utility code" in P and s11n overlap, so 
there would be a small bit of bloat there, but that could all (or 
almost all) be hidden from P::s11n users via s11n's API marshalling 
techniques.

In case you don't know: s11n recognizes 2 different approaches to 
Serializable types: those which directly implement a Serializable 
interface (save/load functions) and those which are proxied via a 
functor. Proxies allow us to, e.g., do this:

typedef std::map<std::string,std::list<int> > MapT;
MapT m;
// ... populate map ...
s11nlite::save( m, somestream );

MapT is proxied by a pair of algos which known how to de/ser std::maps. 
Likewise, std::string and std::list also have proxies. Even though we 
cannot edit those classes, s11n's proxy support allows us to treat them 
as first-class Serializable objects. The only requirements is that the 
type provide the necessary accessors/mutators so that we can 
save/restore the type's state (all std containers provide this).

What this means is that many existing P classes can be transformed into 
Serializables *without touching one line of their code*. If a type does 
not supply the nececssary API, or wants to directly implement a 
Serializable Interface, that's okay, too - s11n provides full support 
for virtual/polymorphic Serializables, including DLL-based loading of 
deserialized types, if needed.

The implication of the proxy support is that we can integrate s11n 
support into P without modifying the P code base. In fact, it could be 
supplied as an optional layer, even from another source tree. Clients 
including the P::s11n layer get serialization, those who don't, don't.

P provides some classes which have HUGE implications for s11n, 
especially the IODevice layer. With streambuf wrappers, or equivalent, 
we could de/ser from/to arbitrary pipes, using, zB, P::ProcessIO. This 
would allow, zB, piping s11n over ssh connections, over HTTP and FTP, 
etc. The uses for this are HUGE, my friends, HUGE! i experimented last 
night with pulling s11n'd data from an http server. i haven't yet 
written over http, but that should be trivial using your http code and 
a CGI/PHP script on the server. That would allow client apps to save 
over the web, bypassing most firewall-related problems of saving over 
the net.

Last night i put together a type to buffer s11n data to/from IODevice 
(or similar), and will attempt to take s11n into the realm of networks 
this weekend.

Potential caveat:
P is more portable that s11n. i have no idea if compilers on HPUX, 
Tru64, AIX, etc., support class templates well enough to use s11n. 
Since i only use Linux and Solaris, and only program using GNU tools, i 
personally can't offer much help when it comes to wide portability. i 
do avoid Linux-only code - i use only std C++ constructs, but i also 
freely take advantage of gcc's excellent standards support, and that 
means excluding older compilers.


Unrelated: build tree problem
Can someone remind me of the proper set of commands to completely 
rebuild the configure script and Makefile.in's? My autotools are newer 
than those in the build tree, and i can't get them to pick up my 
changes to Makefile.am. i haven't used autotools in 2 years or so, and 
have forgotten the various tricks. (My feelings towards autotools 
are... well, they're not nice. See toc.sf.net for why.)


i wish i had found P a lot sooner...

If you'll excuse me now... i've got to go P. ;)

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts