[Esug-list] ESUG SummerTalk - Fuel, binary object serializer
Mariano Martinez Peck
marianopeck at gmail.com
Wed May 25 09:28:00 EDT 2011
Hi Philippe. I don't know why but your emails always go to spam in my
> > Actually, the project has already started since several months. Tristan
> > Bourgois and I started with the project while doing an internship with
> > INRIA. Since a couple of months, Mariano Martinez Peck joined the team,
> > now he is the official mentor in the SummerTalk.
> > ESUG website for SummertTalk:
> > http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011
> > The website with all the necessary information is here:
> > http://rmod.lille.inria.fr/web/pier/software/Fuel
> > It even includes slides explaining the algorithm. In addition, a paper is
> > progress.
> Could you make the slides available in some other format than Flash?
Ok, Martin will do it and upload them directly to the website.
> > For the moment, Fuel already provides the following features:
> > - Fast pickle format. It is much faster to materialize than to serialize.
> What has led to the conclusion that materialization is more important
> than serialization?
One of the most important uses we want to do with Fuel (in a future) is to
be able to use it for Monticello (to replace mzc).
The idea in addition is to be able to boostrap a really small pharo image
(hetzel) and be able to load stuff without needing a compiler.
I all those cases we assume that you serialize only once or few times and
you materialize much more times.
But of course, that does not apply to all cases, like you said about session
> I can image scenarios when there is a one to one
> relationship and scenarios where serialization is more important (e.g.
> session replication).
> > - Correctly support class reshape (when the class of serialized objects
> > changed).
> So what do you do when an instance variable was added? Set it to nil
> and hope that everything will continue to work?
In that example yes. But what we meant is that right now the inst var names
are bening encoded also. So at materializatio ntime we will be able to deal
Not all scnearios are developed right now, but the base is there. At some
point, the only solution has to be done by the user. For example, you should
#updateFrom: aVersion to: anotherVersion: anotherVersion object: anObject
or something like that....
So...we meant that we store the instVar names and we support some type of
In fact, we have reified FLInstanceVariablesMapping. So maybe we can do
something with that in a future.
> > - Serialize ANY kind of object. For the moment there is no object to our
> > knowledge that we cannot serialize and materialize.
> Really? You serialize Socket, Process, FileStream and something
> meaningful happens?
Of course there are classes whose instances doesn't make sense once to load
them back in the image. Our comment was literally: we can (ok, we should be
able to) serialize them and materialize them without problem. Now....whether
those instances are correct or still valid and meaningful in the current
image is another problem ;)
One of the future features will be to be able to implement
#postMaterializationAction or something like that could be executed after
Sockets could try to get a new socket from the OS, Processes could be
restarted and rescheduled? I have no idea. If you have, please let us know.
Thanks for the execellent questions :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esug-list