Magma object serializer

[Mariano Martinez Peck]

On Fri, Jun 3, 2011 at 6:30 PM, Chris Muller <ma.chris.m at 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 :)



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20110609/6f19762f/attachment.htm