Magma object serializer

[Chris Muller]

>>  - Instantiatation / initialization of a MaObjectSerializer.
>>  - Serialization of object graphs of various sizes.
>
> If you have by chance some code snippets to generate graphs for testing
> (maybe you have that in Magma) let us know :)
> We can a pice of code that generates binary trees...

Yes, see MaFixtureFactory.

  MaFixtureFactory current samples

or

  MaFixtureFactory current knot

There was a discussion recently about comparing object graphs -- you
may be interested in MaObjectSerializerTester, and how it verifies
serialized-->remateralized object graphs of any shape against the
original fixture graph.  Very useful for ensuring your serializer is
_working_.  :)  See MaObjectSerializerTestCase>>#testSamples which
sends #maEquivalentForSerializationTest: to determine that..

>> "Serialization"
>> | obj ser |
>> obj := Array with: 1 with: 'string'.
>> ser := MaObjectSerializer new.
>> [ ser serializeGraph: obj ] bench
>>
>
> With the rest of the serializers that we do is to serialize the graph into a
> file. How could we do this with Magma Serializer?
> because serializeGraph: answers a MaSerializedGraphBuffer. So, I guess I can
> ask the byteArray to it and do a nextPutAll: or something like that to our
> stream?

Yes.  I, of course, always appreciated the elegance of the notion that
MaObjectSerializer could operate directly on Streams, but the problem
is that I also want a secure client-server protocol which wraps the
serialized requests and responses.  So to, for example, calculate a
MAC, the full byteArray of the request is required in advance.  It's
ok though, serialized / materialized objects have to fit into memory
anyway, so a streaming API doesn't really offer any practical
advantage - just elegance.

> We also have in Fuel what we call "in memory serialization" that basically
> returns the byteArray and then we can materialize from that. So this case
> would be similar to this usage of Magma, wouldn't it ?

Yeah - similar to use of "Ma object serializer".  (IOW, you don't have
to load Magma to use MaObjectSerializer), you can just load MaBase.

>> As I said, benching is tricky, and publishing comparisons even
>> trickier
>
> yes, exactly. The problem is in addition that there are supported features
> of a serializer that inpacts on the results of a benchmark. For example,
> supported class reshapes, initialization after materialization, support
> transient instVars...etc... to support all those things you usually spend
> more time. So maybe you support all that and in the results you are slower
> in comparisson with someone that do not support that. So yes, measuring
> speed only is not good. But taking into account the rest of the properties
> is better.

Yip!  Glad you said that.

 - Chris