[Seaside] Re: ESUG SummerTalk - Fuel, binary object serializer

[Mariano Martinez Peck]

On Wed, May 25, 2011 at 5:14 PM, Yanni Chiu <yanni at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20110525/18b21462/attachment-0001.htm