[Pharo-project] Object serialization in Pharo

Stéphane Ducasse stephane.ducasse at inria.fr
Tue Sep 15 16:17:44 EDT 2009


> Stef,
>
> Henry's warning tells me I'm not alone in being afraid of Squeak's  
> serializer.  A while ago, I had settled on SIXX as the likely best  
> option for me, but will certainly consider other options.  For the  
> Dolphin filer, my tests mostly center on loading objects with old  
> schemas.  It was fairly easy to do because I had old data in  
> abundance, and simply loaded some of it into new images.  For Pharo,  
> we might write tests that compile a class, serialize, make some  
> changes to the class and reload the "old" data. The details will  
> probably depend on the serializer(s) we select.
>
> My plan has been to start out using SIXX for network transport of  
> data between like images (where schema changes are not a concern)  
> and then begin to look at archival uses if that goes well.
>
> Does that answer your question?

ok we will evaluate SIXX.
Now my point is that we should have good solutions: so if  
referenceStream can be fix we fix it else we trash it.
Half-baked solutions just hinder progress.

My goal is this community is to set the cap (fun for a lighthouse) and  
the cap for 1.2 and other releases.
I want a neat nice robust working documented system and each step  
going in that direction is an important one.
Stef


>
> Bill
>
>
> -----Original Message-----
> From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr 
> ] On Behalf Of Stéphane Ducasse
> Sent: Tuesday, September 15, 2009 1:19 PM
> To: Pharo-project at lists.gforge.inria.fr
> Subject: Re: [Pharo-project] Object serialization in Pharo
>
>> Stef,
>>
>> The packaging constraint had nothing to do with Pharo.  See the [ANN]
>> thread on #readStream replacing ReadStream on: (around 4 Sept).
>> SecureSqueak is the system with the apparent limitation; it really
>> does have that constraint, it will not be of much use to me.
>>
>> Unit tests for a serializer would be well-taken, but I will largely
>> have to start over.  Choosing a filer seems to be the first step.
>> Squeak's ReferenceStream did not strike me as a good option; if you
>> wish to argue in its favor, please do so.  Otherwise, I would like to
>> see SIXX get a good evaluation, as well as any other options that
>> should be considered.
>
> I'm sure that I want an XML parser in the way but why not.
> I started to write some tests just to learn and document. I would  
> even have no problem to throw away everything it there is a better  
> solution. Now what tests will let enable us to change and nothing  
> what we change.
>
> Stef
>>
>> Bill
>>
>>
>> -----Original Message-----
>> From: pharo-project-bounces at lists.gforge.inria.fr
>> [mailto:pharo-project-bounces at lists.gforge.inria.fr
>> ] On Behalf Of Stéphane Ducasse
>> Sent: Tuesday, September 15, 2009 10:06 AM
>> To: Pharo-project at lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] Object serialization in Pharo
>>
>>
>> On Sep 15, 2009, at 4:16 PM, Schwab,Wilhelm K wrote:
>>
>>> Simon,
>>>
>>> I wish you well and will be eager to hear progress reports.  Long
>>> ago, I looked at ReferenceStream (or maybe SmartReferenceStream),  
>>> and
>>> did not like what I found.  IIRC, the output for simple examples was
>>> much larger (of course, it might not continue to scale so
>>> unfavorably) compared that that produced by Dolphin's binary filer.
>>> Another concern was schema changes.
>>>
>>> Dolphin has an orderly conversion process that will raise an error  
>>> if
>>> it is not prepared for what it finds; Squeak seemed to want to fix  
>>> it
>>> itself with the aid of the user (not gonna fly in an end-user app or
>>> a server process, which is pretty much everything).
>>>
>>> Dolphin locates conversion methods in the class of the object being
>>> converted or in the class of a proxy for it (that sounded scary to  
>>> me
>>> when I read about it, but it is exactly what one would want in
>>> practice).  In contrast, Squeak puts the conversion methods in
>>> ReferenceStream.  Yuk!!!  Sorry, don't know what just came over  
>>> me :)
>>> Of course one can always modify ReferenceStream[*], but imagine the
>>> chaos if ReferenceStream were to become widely used.
>>>
>>> I have used serializers to good effect and would like to continue
>>> doing so.  At the moment, I would look again, but would lean away
>>> from ReferenceStream.
>>
>> I started to write some tests in the PharoTaskForces.
>> If people want to join effort because before changing I would like to
>> know what is there.
>>
>>> SIXX (an XML serializer) is a possibility.  As I recall, its output
>>> was not terse (but might compress nicely??).  There originally was
>>> minimal to no support for shape changes, but that has been  
>>> addressed;
>>> I cannot speak for how well it has been done because I have not had
>>> time to look.  It is on my todo list and might float to the surface
>>> soon, though initially I would not need to care about shape changes.
>>>
>>> HTH
>>>
>>> Bill
>>>
>>>
>>> [*] I think we recently discussed a Squeak fork that would not allow
>>> touching base classes due to packaging limitations.
>>
>> really?
>>
>>> Not good.  I am not defending the ReferenceStream example, but it
>>> would be a big problem on that system, if I understood that thread.
>>
>> I would like to fix that
>> We need a good object serializer.
>>
>>
>>>
>>>
>>> -----Original Message-----
>>> From: pharo-project-bounces at lists.gforge.inria.fr
>>> [mailto:pharo-project-bounces at lists.gforge.inria.fr
>>> ] On Behalf Of Simon Denier
>>> Sent: Tuesday, September 15, 2009 8:32 AM
>>> To: Pharo Development
>>> Subject: [Pharo-project] Object serialization in Pharo
>>>
>>> Hi folks
>>>
>>> I'm looking at the code and comments of ReferenceStream for object
>>> serialization and I wonder what is the best strategy to serialize a
>>> partial model. I mean, I want to store all elements found while
>>> traversing the graph of the model, but I dont want to store some
>>> attributes of those elements (i.e., transient attributes).
>>>
>>> Any sample?
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project





More information about the Pharo-dev mailing list