Re: [Pharo-project] [Seaside] Re: ESUG SummerTalk - Fuel, binary object serializer
On Wed, May 25, 2011 at 5:14 PM, Yanni Chiu <yanni@rogers.com> wrote:
On 24/05/11 4:39 PM, Martin Dias wrote:
We really appreciate all kind of feedback and comments. If you want to try it, check in the website how to do it. It is extremely easy.
I had a brief look and will look some more. I may try to use it to serialize a Pier kernel.
heheheheh. We would LOVE that. In fact, I told martin few months ago to do EXACTLY that. If you could give it a try or need help, please let us know.
In another use case, I'd like to serialize from one image, and deserialize in another image - under end user control. The issue here is that "nasty" code could be introduced: e.g. capture the Fuel output, deserialize, add nasty code, re-serialize, then send onward for import to image. Would it be possible to have some sort of "virus" filter? Maybe something like the Star Trek transporter that can filter out nasty stuff before re-materializing. :) For a start, maybe an inclusion list and/or an exclusion list of classes and globals would be useful.
I guess this should be easy to do. For the moment: - globals objects are hardcoded in #globalNames - globals behaviors (classes and traits) are managed (by default) in kind of "light" serialization. Where we only serialize the global name which means that the class has to be present in Smalltalk globals in the image that you want to materialize. You can change the default behavior and be able to completely serialize a class/trait. But this is much more complicated and it is still work on process (ClassBuilder is not your best friend). Cheers -- Mariano http://marianopeck.wordpress.com
On 25/05/11 11:22 AM, Mariano Martinez Peck wrote:
- globals behaviors (classes and traits) are managed (by default) in kind of "light" serialization. Where we only serialize the global name which means that the class has to be present in Smalltalk globals in the image that you want to materialize.
You can change the default behavior and be able to completely serialize a class/trait. But this is much more complicated and it is still work on process (ClassBuilder is not your best friend).
Okay. I think all that is needed is a "safe mode" option when *de-serializing*, which would discard any non-light classes or global objects that appear in the stream.
On Wed, May 25, 2011 at 5:31 PM, Yanni Chiu <yanni@rogers.com> wrote:
On 25/05/11 11:22 AM, Mariano Martinez Peck wrote:
- globals behaviors (classes and traits) are managed (by default) in kind of "light" serialization. Where we only serialize the global name which means that the class has to be present in Smalltalk globals in the image that you want to materialize.
You can change the default behavior and be able to completely serialize a class/trait. But this is much more complicated and it is still work on process (ClassBuilder is not your best friend).
Okay. I think all that is needed is a "safe mode" option when *de-serializing*, which would discard any non-light classes or global objects that appear in the stream.
Sorry Yanni, I didn't follow. Could you please explain a bit more? what do you want to serialize? do you want to be able to choose some classes as light and some as non-light? where do you want to materialize ? in the same image or in another one ? When you said discard....what would you do with the instances of those non-light classes for example? you don't materialize them? and what happens to the objects that were pointing to them ? why would be the scenario useful for ? security ? Thanks -- Mariano http://marianopeck.wordpress.com
participants (2)
-
Mariano Martinez Peck -
Yanni Chiu