Features Download

From: Mariano Martinez Peck <marianopeck-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>
Subject: Fuel vs. StOMP (answer to blog post of Runar Jordahl)
Newsgroups: gmane.comp.lang.smalltalk.pharo.devel
Date: Wednesday 13th July 2011 08:56:51 UTC (over 7 years ago)
Hi guys. Several people asked several times the differences between the two
"new" serializers Fuel and StOMP. Runar wrote several blog posts about it:


So I would like to give you my point of view as a Fuel developer. Which are
the main differences between Fuel and StOMP?

1) Portability. What that means?   "portability" is too wide to just talk
without details. For me, portability in this case means two things:
format and portable code.
Portable format:  In a dialect/language XXX be able to materialize a 
which was serialized in a dialect/language YYY.
Portable code: That the code of the serializer can also work in another
dialect/language (not necessary including portable format).

Fuel will does not do focus in portable format. At least, we will not do
extra effort to support that. Regarding portable code, it is not Fuel first
goal to be portable to other dialects but it is not that difficult anyway.
In fact, Fuel has been even ported to Newspeak. In the contrary to Fuel,
StOMP wants to be portable in both ways, format and code. But of course, it
is difficult to find portable representation of certain objects like
BlockClosure, MethodContext, Class, Trait, etc. StOMP do not deal which
objects due to the lack of those portable representations. In Fuel, we can
serialize those objects but not in a portable way.

So...next differences are:

2) In Fuel we want to be able to correctly serialize *any* kind of object.

3) Fuel will try to get the fastest way to serialize or materialize an
object. StOMP will use the most fastest available while trying to generate
portable representation.

4) Another important difference is that Fuel is faster in materialization
and StOMP in serialization. Why? Because a tool build on top of Fuel will
used for code management and loading is done much more times than saving
(think as in parcels). Notice that this doesn't mean we are slow in
serialization. We are faster than most of the serializers, but not as much
as StOMP.
What are the reasons of the differences in performance?  because of their
design and internals. It is a trade-off. To be faster at materialization,
do some extra work in serialization. StOMP does not do extra optimization
for materialization and hence serialization is faster.

What is that "extra" we do?  Ok, we have wrote a whole paper for IWST 2011
so I won't repeat myself. I will let you know when we get the notifications
of the paper so that we can make it public.

Regarding your excellent paragraph: "But... A partial solution would be to
use an intermediate format for *serialization*. This format would support
fast serialization, and therefore be similar to StOMP's format.
The intermediate format would for example be used when a user needs to
quickly commit changes to a database. Later, the intermediate format could
be transformed to a format that is better optimized for *deserialization*.
This transformation would typically be done as a background task. The
deserializer would be able to (transparently) understand both
the intermediate format and the optimized format."

I can just tell you that it is an excellent idea and we talked with Martin
about it, but I am not sure about how easier it would be. Maybe it is just
easier to have 2 serializers with 2 different goals :)

Regarding "To me it appears like StOMP has better support
for serialization/deserialization "hook"
class renaming<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/renaming>
shape changing<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/shapechangers>.
Hopefully, Fuel can learn from StOMP in this field."   I totally agree.
StOMP's hook methods are awesome and we want to have the same in Fuel. In
fact, check the issue tracker and you will see several open issues
this :)
I think class renaming and shape changing are fine in Fuel.

Finally, notice that we are not "competitors". We have sent several private
emails between us and Masashi UMEZAWA and we are trying to share as much as

CD: 90ms