Hi Rob,

> Magma is very cool.

Very kind, thank you.

> I am looking at MaObjectSerializer for use in SqueakElib.  The 
> traversal protocol is great - I like it a lot.   Do you have any 
> writeups on how to customize one's own serializer?

Not yet.  The 'Ma object serialization' package is intended to be generally
useful as a serializer, and pluggable in certain areas to accomodate varying
needs.  It is currently independently used by Magma and Ma client server.  One
of the things I still want to do before I publish it indepenedently on
SqueakMap is to make the encoding pluggable, and supply an XML plug-in as an
example.  Unfortunately, this is still more than a couple from the top of my
list right now.

> 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".

> This substitution test should also apply to the 
> rootObject being appended into the Serializer.  

Agreed, however, it currently doesn't do that.  Magma didn't end up using the
substitution functionality, that's why I haven't caught this yet.  It looks
like this can be fixed by changing the second line in
MaObjectSerializer>>appendGraph:do: to:

	...
	oneArgBlock value: (traversalStrategy substituteFor: anObject).
	...

> 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, 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 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!

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

Cheers,
  Chris


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com