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