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

[Christian P. <cp...@se...>]

Am Samstag 18 Dezember 2004 13:50 schrieb stephan beal:
> 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.

I would definetly love to see serialization inside P::Classes !

> 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.

Really neat!

> 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.
>

Platform portability is mainly archived by the P::Classes core library.
We also use gcc's excelent standard support - that means that we have to use 
gcc3 on all UNIX platforms. But we have to take care that the code base 
compiles fine under Visual C++ .NET (Win32).

> 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.)

try "autogen.sh" in the root dir of the build tree.

>
> i wish i had found P a lot sooner...
>
> If you'll excuse me now... i've got to go P. ;)

As marc already mentioned, i'm currently doing a refactoring of the P::Classes 
framework. Maybe we can work together to bring all the neat features right 
into it. 


Regards,

Christian