Re: [qub] Re: [fU] 1) Serializable is almost dead, 2) libfun direction proposal

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

Hey, man :)

On Sunday 12 October 2003 11:38, Rusty Ballinger wrote:
> (sorry I'm so far behind here!)
>
> One thing I wanted to say about an earlier message of yours (a few
> weeks ago?), I think your idea of having the class have a
> getSerializableClassName() (or whatever) & having the serializer call
> that, instead of having the class call setSerializableClass() in its
> serialize(), is good.
>
> At first I was resistant because it's one more thing for
> Serializables to implement (a 50% increase in the API, appalling!!),
> but if the base class version is something like

Last night i managed to completely remove the classname thing from the 
client interface - this is now set up as part of the classloader 
registration, competely behind the scenes.
As it turns out, it's a 33% reduction in the Serializable API, no change 
to the s11n_node (SerialTree) API and a one-line addition to a "hidden, 
macro-time only" class.

Additionally, i managed to do the INSTANTIATOR equivalent in a way which 
is collision-safe. That is, foo::Foo and bar::Foo will no longer 
collide when creating new_Foo(), since this is all done via template 
specializations now, and those specializations can only collide if you 
register the same class twice (i.e., call INSTANTIATOR twice).

>     return ClassLoader::getTypeIDName(typeid(*this));

That's essentially what i was doing by Saturday night, but that's all 
history now. :)

> > indirectly called during calls to de/serialize().
>
> Hmmm... well... (but you *can* still subclass Serializable?  I
> haven't read your later messages yet, but it sounds like this is no
> longer necessary?)

You can, but you don't need to. You need to subclass /some/ 
Serializable, but it can be your own type if you want.

> The main thing which makes me unsure that this is a feature is, if
> you have a Serializable class, you know exactly where to look for the
> serialize() and deserialize() code, because the API tells you.  (And

This is all done via the SerialTree now (s11n_node). i'll send you a doc 
soon - i spent about 8 hours rewriting it yesterday.

> doxygen etc. will document this for you.)  It sounds like with the
> template version, you still need methods which have the same
> semantics as serialize() & deserialize(), but now they can be called
> something else, and you have to look at the template instantiation to
> find out what their real names are?

Almost, but not quite. Instead, the only API the user interacts with the 
s11n_node. From there the "real" API is hidden by a template-based 
adapter which directs the calls to the proper Serializable interface.


> - it sounds like the qub tree is being abandoned, but there are still
>   things I want out of it:

Not really - just haven't touched it in a while.

>   - libfunUnit (the map & related stuff) - should I move that into
>     the libfun tree?  (I don't have a problem converting that to the
>     new s11n API.)  I have other little things which use it, but they
>     have to set their LD_LIBRARY_PATH to a built qub tree, which
>     isn't so good.

That's a good question. i don't have a good answer for you, though - 
that's up to you.


>   - loubetomy - it was sooo close to being something people could
>     play with!  If qub's install target is never coming back, I
>     should move this out too.  (sniff)  (I think it's preferable to
>     keep qub & loubetomy together, if people can install them!)

That sounds perfectly reasonable. QUB isn't dead, i've just been so 
enthralled with this new code that i haven't touched it. i've got far 
too much time invested in QUB to abandon it!

> - I haven't looked at the stuff you've checked in yet, but is there
>   still a binary format, or is it all convert-to-string during
>   serialization?

Currently it's all string, but i would love a binary format.

>  (I'm not sure, but I *think* the elimination of the
>   string conversion business is the reason the binary format was so
>   much faster.) 

i would fully believe that.

> It would be nice if we can keep that performance
>   gain; my recollection is that it made the difference between large
>   objects being usable & not usable.  (But the problem might just
>   have been that my text parser was bogus :)

i agree completely. i looked at the fun binary format but it relies on 
Qt's stream handling for taking care of things like byte orderings and 
whatnot. Doing a binary format using stl streams is, at the moment, 
over my head :(.


> - Is the old serialization text format still supported?  (As long as
>   there's a way for me to convert from the old format, I'm happy; I
>   just have a lot of old serialized objects I'd still like to be able
>   to use.)


XML and TXT are both supported, but plus 4 additional formats. 
Conversion is easy:

s11nconvert -f input -oX [X == format] -o outfile

> (ha ha, we could request a new project, move the source over, and
> have them kill libfunutil...)

LOL! Go right ahead!


> Anyway, I'm looking forward to trying this out!  Where's the best
> place to start, tests/s11n?

source code:

http://stephan.rootonfire.org/s11n-0.1.0.tar.gz
(version number is bogus)

i'll get it into libfun in the next day or two - i've been waiting on 
your okay before doing that. Don't use the one which is in libfun right 
now - that's some two weeks old - ANCIENT.

sources are under lib/s11n and lib/toolbox
build as normal, then:

cd lib
export LD_LIBRARY_PATH=$PWD
(^^^^ yeah, yeah, i know!)
cd ../client/s11nconvert
./s11nconvert -?

samples:
./s11nconvert -f in.s11n -d -op
should read in in.s11n (which is in fun::txt format), deserialize it 
(-d) and write it out in s11n::parens format (-op). That also loads two 
classes, FooClass and BarClass from a single .so file (BigSO.so). The 
-d flag is mainly for testing - normally objects are not automatically 
deserialize()d.

Run with [-v -cldebug -nodedebug] to get more debuggering output than 
you want (but some insight on how the classloader works). Some CL 
operations happen pre-main(), before -cldebug can take effect, so 
you'll need to set CLASSLOADER_DEBUG=1 in toolbox/ClassLoader.h if you 
want /all/ CL debugging output. Note that the classloader is 
project-neutral, as is the DLLLoader (see DLLLoader.h).
The class FakeRoot, in s11nconvert's main.cpp, shows a demo using a 
different Serializable interface within the FakeRoot's deserialize() 
(called d9e, for reasons explained in the Serializer API docs).

Extensive docs are in doc/s11n.lyx, and i've made a point to keep the 
API docs current (doxygen only, as kdoc doesn't play well with 
templates). See section 2.0 for a summary of the architecture, plus 
some notes about where it diverges from libfun's s11n.

There are a million things to say about the library at this point, but 
i'd rather not re-type what i've entered 4 times into the manual 
already ;).

i'm looking forward to your opinions.

-- 
----- st...@ei... - http://www.einsurance.de
"... NOT because we are America's poodle ..." Tony Blair, 30.9.2003