[Esug-list] ESUG SummerTalk - Fuel, binary object serializer

Martin Dias tinchodias at gmail.com
Thu May 26 02:15:45 EDT 2011


On Wed, May 25, 2011 at 10:28 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

> Hi Philippe. I don't know why but your emails always go to spam in my
> account :(
>> > Actually, the project has already started since several months. Tristan
>> > Bourgois and I started with the project while doing an internship with
>> RMoD,
>> > INRIA. Since a couple of months, Mariano Martinez Peck joined the team,
>> and
>> > 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 in
>> > 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.

Yes, sorry. I kept the embedded slides but I added links to the pdf

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

Actually, despite we have this hypothesis (de-serialization is done much
more often than serialization), I often think it is not something really
essential to the project. It was an early decision to base on the Parcel's
algorithm, which has this feature, but I believe we can eventually implement
an alternative strategy that favors serialization performance over

I think other more essential features (or goals!) are:
- any object can be serialized.
- binary class load, without compilation.
- fast and focused on just one dialect, don't worry about an inter-platform
- flexibility, for selecting the graph to serialize.

>> 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
>> has
>> > 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
> with them.
> 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
> implement
> #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
> changes.
> In fact, we have reified FLInstanceVariablesMapping. So maybe we can do
> something with that in a future.

I want to let the user configure an initialization block.

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

Yes... maybe I was too much optimistic with this "ANY". I think you can
serialize and deserialize instances of these classes but probably they need
something to be "meaningful".

> Thanks for the execellent questions :)

> --
> Mariano
> http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.esug.org/pipermail/esug-list_lists.esug.org/attachments/20110526/769ffcf8/attachment-0002.html>

More information about the Esug-list mailing list