On Wed, May 25, 2011 at 1:10 PM, Yanni Chiu
<yanni@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 sufficient.
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 validation check.
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).
�