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.
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.
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.
- 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. Thanks for the execellent questions :) -- Mariano http://marianopeck.wordpress.com