[Seaside] ESUG SummerTalk - Fuel, binary object serializer

Runar Jordahl runar.jordahl at gmail.com
Wed May 25 08:51:48 UTC 2011

I see three main uses for serializers:

-	Storing objects in databases and files.
-	Deep copy without manually having to implement copy methods.
-	Comparing objects.

The last use is complex: Given two (possibly complex) object graphs,
you could serialize both to a (separate) byte array, and then compare
the two byte arrays to implement #=. In theory this could be a lot
easier than manually implementing the comparison. However, depending
on the serializer and the contents being serialized, the byte arrays
could represent two “equal” objects, but still have different byte

-	“Equal” objects, represented by unequal objects: One graph has
Integer 0, the other one has Float 0.0
-	Objects stored in different order: A Smalltalk Set being equal in
the two graphs can have the element stored using different ordering.
-	Object IDs which should not be part of the comparison, would make
the two byte arrays different.

I am sure there are cases where a serializer could be used to
implement #=, but I have so far not seen it used.

I am looking at using Riak ( http://wiki.basho.com/ ) with Pharo. When
storing a “business object” you  have two choices:

-	Store a binary BLOB representing your object graph.
-	Store the object graph as JSON data.

The last option essentially means you must do something similar to OR
mapping, so I would prefer the first option. With Riak, you will soon
be able to store additional indexed properties, which you later will
be able to query. So you store your whole business object as a BLOB,
together with those properties you need to query.

I never tested SIXX with anything large. Saving space and time is of
course a valid reason to make a new serializer. If you use SIXX you
might need to compress the XML before storing it, adding even more

I really look forward to improvements in Fuel. Good luck!


More information about the seaside mailing list