On Monday, June 9, 2003, at 11:12 PM, Chris Muller wrote:

>> Magma is very cool.
>
> Very kind, thank you.

Chris, it looks like it took at least several weeks for you to write 
Magma.    It was quite generous of you to release it to Squeak.


>> I need the ability to "pass-by-proxy" by substituting a Descriptor
>> object for the pass-by-proxy object when serializing and I need to
>> substitute a handler object when I materialize a Descriptor.  Is there
>> a way to do substitutions based on the class of the object being
>> pickled, or let the serializer decide by callback, for each node in 
>> the
>> graph traversal?
>
> If I understand your question correctly, the answer is yes.  By giving 
> your
> serializer your own customized instance of a 
> MaObjectGraphTraversalStrategy:
>
> 	mySerializer := MaObjectSerializer new
> 		traversalStrategy:
> 			(MaObjectGraphTraversalStrategy new
> 				substituteNonSpecifiedNodesUsing: [ : passByProxyObject | self
> descriptorFor: passByProxyObject ]);
> 		yourself
>
> descriptorFor: would be your converting method for converting your 
> passByProxy
> object to a "descriptor".

awesome.  This is just the ticket for the serialize side.  It will be 
easy to determine the type of descriptor to substitute.


> 	oneArgBlock value: (traversalStrategy substituteFor: anObject).

ok.


>> Anyway, I would need
>> the Serializer involved in any substitutions made, so I could control
>> the OIDs that I issue into the descriptors.
>
> No problem, since you give it the substitution block.  On the 
> materialization
> side,

Yes, there is an issue here on the materialization side.   When 
materializing a byteArray, I also need to substitute objects for 
descriptors.  It looks like the traversalStrategy only works when 
scanning the object graph for serialization and not when materializing 
the byteArray.  Would it be problematic to allow 
MaObjectSerializer>>newSkeletonFor: to do "desubstitution" with the 
traversal strategy?

or...

> I remember now why plain ol'e ByteObjectBuffers to name the global 
> worked
> much better for me with Magma than substitutions.  In the 
> materialization
> process, the framework ends up creating a basicNew instance of the 
> object and
> then setting its instVars one by one from the buffer (taking its oids 
> and
> looking up the objects for them).  If, at that point, it creates an 
> "interim"
> instance of a "Descriptor" you're going to eventually want to 
> translate it back
> to the original object (e.g., Smalltalk or Processor), which requires 
> a become:
> since it could be referenced from many objects in a single 
> materialization.
>
> So I instead used a ByteObjectBuffer for those objects and overrode
> maMaterializeFrom: aMaByteObjectBuffer on their class side to just 
> answer the
> appropriate global rather than the new skeleton.

I'll have to look deeper;  but I can't right now.  You seem to be 
recommending that I use special ObjectBuffers that materialize to the 
correct object.  The difficulty is that I need to register connection 
oids for this ObjectBuffer.  I don't see where I could do that, since I 
don't have a reference to the serializer in this method.


> I only mention this because, if substitutions ends up not working for 
> you,
> e-mail me again.  This serialization framework can pretty much do 
> anything if
> you're willing to override methods or classes.
>
>> It would also be nice to change the encoding, but i think this is done
>> by changing the registered Buffer types - this seems more
>> straightforward than doing substitutions at the moment.
>
> I really hope to get to that XML plug-in someday!

That would be great.

> Good luck, let me know how it goes and whatever I can do to help.

thanks very much, Chris.   I need to get some sleep before I look into 
it again.  :)

cheers,
Rob