On Fri, Jun 3, 2011 at 6:30 PM, Chris Muller
<ma.chris.m@gmail.com> wrote:
>> - 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..
Thanks Chris. We have looked at it (and still are).
>> "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.
Ok. So if aStream is a fileStream for example, then the following two methods are correct:
>> serialize: anObject on: aStream
| serializer graphBuffer classDefinitionsByteArray graphBufferByteArray |
aStream binary.
serializer := MaObjectSerializer new.
graphBuffer := serializer serializeGraph: anObject.
classDefinitionsByteArray := serializer classDefinitionsByteArray.
graphBufferByteArray := graphBuffer byteArray.
self nextByteArrayPut: classDefinitionsByteArray on: aStream.
self nextByteArrayPut: graphBufferByteArray on: aStream.
and
>> materializeFrom: aStream
| size classDefinitionsByteArray graphBufferByteArray |
aStream binary.
classDefinitionsByteArray := self nextByteArrayFrom: aStream.
graphBufferByteArray := self nextByteArrayFrom: aStream.
^ MaObjectSerializer new
classDefinitionsByteArray: classDefinitionsByteArray;
materializeGraph: graphBufferByteArray
>> nextByteArrayPut: aByteArray on: aWriteStream
aWriteStream
nextNumber: 4 put: aByteArray size;
nextPutAll: aByteArray
>> nextByteArrayFrom: aReadStream
^ aReadStream next: (aReadStream nextNumber: 4)
is correct?
I, of course, always appreciated the elegance of the notion that
MaObjectSerializer could operate directly on Streams,
what do you mean to "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.
ok I understand.
> 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.
Good!! we didn't know. Martin fixed that now :)