[Pharo-project] [Seaside] Re: Re: ESUG SummerTalk - Fuel, binary object serializer
tinchodias at gmail.com
Thu May 26 08:55:52 CEST 2011
On Wed, May 25, 2011 at 1:10 PM, Yanni Chiu <yanni at rogers.com> wrote:
> On 25/05/11 11:53 AM, Mariano Martinez Peck wrote:
>> 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 ?
> Yes, security. Here's my first post again, with different formatting:
> In another use case, I'd like to serialize from one image, and deserialize
> in another image - *under end user control*. [e.g. web app]
> The issue here is that "nasty" code could be introduced:
> - 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?
> So a simple "safe-mode" option on de-serialization would probably be
It is a good point.
For the moment, when you deserialize a full class into the image, their
methods are created, and bytecodes are copied from the stream without any
Anyway, you could deserialize the class, run your own validations, and then
install the class (I mean, add the class to Smalltalk globals, do the class
initialization, run announcements).
> seaside mailing list
> seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project