[Seaside] ESUG SummerTalk - Fuel, binary object serializer

Mariano Martinez Peck marianopeck at gmail.com
Wed May 25 10:38:54 UTC 2011

On Wed, May 25, 2011 at 10:51 AM, Runar Jordahl <runar.jordahl at gmail.com>wrote:

> I see three main uses for serializers:
> -       Storing objects in databases and files.
> -       Deep copy without manually having to implement copy methods.
> -       Comparing objects.
We took note, thanks :)

> 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
> contents:
> -       “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.

Ok, I understand. So, we can provide something like this API:

byteArray := FLSerializer serializeInMemory: myObject


myRecoveredObject := FLMaterializer materializeFromByteArray: aByteArray

would something like that help ?

> I never tested SIXX with anything large. Saving space and time is of
> course a valid reason to make a new serializer.

Sorry, I didn't want to look rude with my answer. But the two times we sent
something about Fuel to the mailing list, the answers we received were "stop
reiveinting the wheele". And this is completly the opposite. Why I am doing
Fuel ? for fun? no. For fun I have other projects. I do it because I NEED it
for my PhD. I would like not to spend time of Fuel and directly concentrate
on my topic. But I need a fast serializer that could serialize ANY kind of
object in the image: MethodContext, Continuations, BlockClosure,
CompiledMethos (with all kind of trailers and types), MethodDictionaries,
full Classes and Traits, Set and Dictionaries without problems. Don't have
problems with global references, support class re-shape, etc.  In addition,
I need to be able to understand the serializer, extend it and make sure it
works. Fuel is really OOP, I can understand it, extend it for my own use,
and very well tested/benchmarked.

> If you use SIXX you
> might need to compress the XML before storing it, adding even more
> overhead.
> I really look forward to improvements in Fuel. Good luck!


> Runar
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20110525/e6455da2/attachment-0001.htm

More information about the seaside mailing list